Radicle hasta 1.10.3 envía repos privados en texto plano

Radicle, una red entre pares para compartir repositorios Git, reveló el 23 de septiembre de 2026 que todas sus versiones publicadas envían el tráfico de red sin cifrar. Un segundo fallo permite a un atacante hacerse pasar por un par de confianza. Juntos significan que los repositorios privados sincronizados con Radicle pueden ser leídos, o robados, por cualquiera en la ruta de red. Todavía no existe una versión corregida.

La divulgación del proyecto Radicle pide a los usuarios que dejen de usar repositorios privados en la red de inmediato. También pide tratar como comprometidos los datos privados ya descargados.

Los dos fallos

Los nodos de Radicle se comunican directamente entre sí, sin un servidor central como GitHub. Cada conexión empieza con un saludo inicial basado en Noise, un método conocido para establecer enlaces cifrados. Ese saludo debe demostrar quién es cada parte y luego cifrar todo lo que sigue.

Según Radicle, ninguna de las dos mitades funciona como debería:

Fallo	Qué sale mal	Reportado
Transporte en texto plano	Los datos tras el saludo inicial se envían sin cifrar	24 de junio de 2026, por Konstantinos Maninakis
Autenticación de pares rota	Un atacante puede hacerse pasar por un par de la lista de permitidos	12 de agosto de 2026, por cryptocode

La lista de permitidos es la forma que tiene Radicle de limitar un repositorio privado a pares concretos. El segundo fallo la anula. El texto de Radicle expone el riesgo sin rodeos: "La amenaza realista es cualquiera en la ruta entre tu nodo y el nodo con el que se sincroniza, y ningún ajuste ni lista de permitidos protege contra ellos."

Dónde está el error

Maninakis, que encontró el primer fallo, publicó un análisis técnico el mismo día. Lo atribuye a un error de lógica en un método llamado Protocol::write. Unas condiciones escritas para SOCKS5, un protocolo de proxy común, se reutilizaron para el transporte Noise. Como resultado, el cifrado nunca se activaba tras el saludo inicial.

Él muestra lo visibles que son los datos. En una conexión real a un nodo semilla de producción, el primer byte tras el saludo inicial es la letra "r" de "rad". "Cualquiera en la ruta de red entre dos nodos...puede leerlo todo", escribe.

El fallo está en una biblioteca compartida, no solo en Radicle. Una issue abierta en el repositorio netservices.rs dice que el código de NoiseSession pasa las escrituras directamente a la conexión interna una vez termina el saludo inicial. "Quien pueda observar la conexión puede leer los datos de la aplicación", dice la issue. También advierte que cualquiera capaz de alterar el flujo puede saltarse la autenticación por completo.

Cuándo llegará un arreglo

Todavía no. Radicle dice que el arreglo requiere subir la versión principal, no un parche.

Las dos fuentes describen el reemplazo de forma algo distinta. El texto de Radicle dice que la configuración propia de Noise se sustituirá por la pila entre pares iroh. Maninakis escribe que Radicle 2.0, aún sin publicar, usará QUIC y TLS mediante rustls, una biblioteca de cifrado en Rust. Ambas coinciden en que el cambio rompe la compatibilidad con la red 1.x. Así que los nodos viejos y nuevos no podrán comunicarse.

Maninakis dice que todas las versiones hasta la 1.10.3 están afectadas. Radicle dice que lo están todas las versiones publicadas. Ninguna fuente da un identificador CVE.

Qué significa esto para los desarrolladores

Si alojas repositorios privados en Radicle, deja de sincronizarlos por la red ahora. El texto de Radicle propone bloquear su distribución con rad block <RID>, usando el ID del repositorio.

Da por hecho que todo lo ya sincronizado ha sido visto. Revisa esos repositorios en busca de secretos como claves de API, tokens y contraseñas, y cámbialos. Radicle aconseja tratar como comprometidos los datos privados ya descargados, y una clave en un historial de Git cuenta.

Si tienes que seguir sincronizando, envuelve el tráfico en una capa que controles. Radicle menciona VPN, WireGuard y túneles SSH como medidas de mitigación. Añaden el cifrado que le falta al protocolo.

Los repositorios públicos nunca fueron secretos, así que el fallo del texto plano les afecta menos. Aun así, conviene seguir el fallo de suplantación, porque socava la certeza de un nodo sobre con quién está hablando.

Planifica la actualización a 2.0. Como rompe la compatibilidad, todos los nodos de los que dependes tendrán que migrar más o menos a la vez. Si usas la biblioteca netservices.rs en tu propio proyecto, sigue la issue #48, porque el mismo error puede afectarte.