Radicle admite dos fallos críticos y pide dejar de usar repos privados
Todas las versiones de la pila de colaboración sobre Git son vulnerables: el tráfico entre nodos viaja en claro y el handshake permite suplantar Node IDs de la lista blanca.

Radicle, la pila de colaboración de código peer-to-peer construida sobre Git, ha publicado dos vulnerabilidades críticas en el protocolo de red que usan sus nodos. Todas las versiones publicadas hasta la fecha están afectadas y no habrá parche compatible: el arreglo rompe el protocolo en el cable, así que subirá el número de versión mayor. Hasta entonces, el proyecto recomienda dejar de usar repositorios privados sobre la red.
Los fallos están en la capa de transporte, no en el modelo de datos del repositorio. Los objetos de Git y las referencias firmadas se siguen verificando en la capa de almacenamiento, así que un atacante no puede falsificar código ni identidades. Lo que se rompe es la confidencialidad del canal y la autenticación de los pares.
El primero es que el tráfico entre nodos no va cifrado ni autenticado. Cualquiera que pueda observar el camino de red entre dos nodos lee en claro todo lo que intercambian. En repositorios públicos el daño es menor; en privados, es el problema entero. Lo reportó Konstantinos Maninakis el 24 de junio de 2026 y publicó aparte su análisis del fallo.
El segundo es que la autenticación de pares en el handshake está rota: un atacante puede conectarse a tu nodo presentando un Node ID que no es el suyo. Los repositorios privados se comparten solo con Node IDs en lista blanca, así que quien falsifique uno de esos puede descargar el repositorio directamente, sin necesidad de estar en el camino de red. Lo reportó cryptocode el 12 de agosto.
Por separado, el segundo fallo es más difícil de explotar de lo que suena: hay que conocer un Node ID de la lista blanca, y esa lista no es pública. El interés está en combinarlos. Un atacante situado en el camino ve los Node IDs de ambos extremos de una conexión, y normalmente los dos están autorizados. Con eso lee lo que se intercambia y después usa uno de esos identificadores para pedir el repositorio completo cuando le convenga. El escenario realista es cualquiera en el camino entre tu nodo y aquel con el que sincroniza, y contra eso no protege ninguna configuración ni lista blanca.
Qué hacer mientras tanto
El proyecto pide parar de sembrar repositorios privados. Para listarlos, rad ls --private --all; para bloquear uno concreto, rad block <RID>. Recomiendan block y no unseed: unseed elimina la política del repositorio y el nodo cae en la política por defecto, que es block, pero si la cambiaste a allow el nodo sigue sirviéndolo. Para parar el nodo entero, rad node stop.
Nada de eso borra la copia local ni alcanza a los pares que ya descargaron el repositorio: sus nodos tienen los mismos fallos y hay que pedirles que bloqueen también. Tampoco deshace una exposición pasada. Cualquier repositorio privado que haya viajado por la red hay que darlo por filtrado, y si llevaba credenciales, claves o tokens sin cifrar, toca rotarlos. Usar Tor, I2P, otra red superpuesta o una VPN no basta: ocultan el tráfico, pero no evitan la suplantación de pares.
Queda el arreglo. Radicle va a sustituir su protocolo de red actual, uno propio montado sobre Noise, por iroh, una pila peer-to-peer open source. Sin negociación de versiones y con un cambio incompatible en el cable, no hay mitigación retrocompatible posible. El proyecto no ha dado fecha para la versión corregida.


