Radicle, la plataforma de colaboración de código peer-to-peer construida sobre Git, ha revelado dos vulnerabilidades críticas en su protocolo de red. El proyecto advierte que todas las versiones publicadas hasta la fecha están afectadas, y aún no hay un parche. Las fallas permiten a los atacantes leer datos privados del repositorio en tránsito e impersonar otros nodos, y solucionarlas romperá la compatibilidad con el software más antiguo.
La revelación viene con una recomendación contundente: dejar de usar repositorios privados hasta que se publique una solución. El proyecto dice que está trabajando en una resolución, pero la naturaleza del problema significa que se requiere una reescritura completa del código de red subyacente. Esa reescritura forzará un aumento importante de la versión, lo que significa que los clientes más antiguos dejarán de funcionar con los servidores más nuevos y viceversa.
«Con esta revelación, nuestro objetivo es, ante todo, ser honestos y claros sobre la situación, para que los usuarios puedan evaluar y actuar en consecuencia, mientras trabajamos en una resolución.»
Las Dos Fallas
Los nodos de Radicle se comunican entre sí utilizando un protocolo de red personalizado. La primera falla es que este tráfico se envía en texto plano, lo que significa que cualquiera que escuche en la ruta de red entre dos nodos puede leer todo lo que se está intercambiando. Konstantinos Maninakis informó de este problema el 2026-06-24, y escribió sobre él en su sitio personal.
La segunda falla es que el protocolo de enlace de mano no autentica correctamente los nodos. Un atacante puede conectarse a un nodo de una víctima y hacerse pasar por otra persona, presentando un ID de Nodo que no le pertenece. Los repositorios privados se comparten solo con ID de Nodo que están en una lista de permitidos, por lo que un atacante que falsifica uno de esos ID puede recuperar un repositorio privado directamente, sin necesidad de estar en la ruta de red entre los dos puntos finales.
Cryptocode informó de esa falla el 2026-08-12, y el proyecto propuso una solución upstream, que está enlazada en la revelación. Ambos problemas ahora son públicos.
Cómo Funcionan las Dos Fallas Juntas
Las dos vulnerabilidades son más peligrosas cuando se utilizan juntas. Un atacante en la ruta de red entre dos nodos puede observar el intercambio de información de la conexión y ver los IDs del Nodo en ambos extremos. Esos IDs casi siempre están en la lista de permitidos, porque los nodos típicamente se sincronizan con personas en las que confían. El atacante puede entonces leer lo que se intercambia mientras observan, y más tarde usar uno de los IDs que vieron para obtener todo el repositorio bajo demanda.
La amenaza realista, según la divulgación, es cualquiera en la ruta entre su nodo y el nodo con el que se sincroniza. Ningún ajuste o lista de permitidos protege contra ellos. El ataque funciona incluso si nunca se ha conectado al atacante antes.
Lo que los Usuarios Deben Hacer Ahora
El proyecto recomienda tres pasos:
- Dejar de usar repositorios privados a través de la red hasta que se publique la actualización de seguridad.
- Dejar de sembrar repositorios privados, como se describe a continuación.
- Considerar todo repositorio privado que haya transmitido a través de la red a otro nodo como filtrado.
Si un repositorio contenía credenciales, claves o tokens sin cifrar, la divulgación aconseja rotarlos inmediatamente. El proyecto también advierte que transportes adicionales cifrados como Tor, I2P u otras redes superpuestas o soluciones VPN no son suficientes para proteger los datos. Ocultan el tráfico de red de un atacante a lo largo de la ruta, pero no previenen la suplantación de identidad del par, y un ataque dirigido y sofisticado aún podría conducir a la exfiltración del contenido de los repositorios privados.
Detener la Siembra
Para detener la siembra de un repositorio privado, los usuarios deben cambiar la política de siembra para cada repositorio individual. La divulgación proporciona una secuencia de comandos:
- List the private repositories in storage:
rad ls --private --all - Change the seeding policy to «block»:
rad block <RID> - Optionally, stop the node completely:
rad node stop
The disclosure notes that rad block is preferred over rad unseed, because unseed removes the seeding policy entirely and causes a node to fall back to its default behavior. On a default configuration, unseed is enough, but if the default seeding policy has been changed to «allow», the node keeps serving the repository anyway. block sets an explicit policy that the node checks first, so it works either way.
Lo que Esto No Corrige
Stopping seeding does not delete your local copy of the repository. The copy stays in the storage directory at $(rad path)/storage/<RID without the rad: prefix>. Removing that directory deletes the repository and every fork of it that you hold. The disclosure advises caution: remove it only if you understand what you are doing.
Detener la siembra tampoco alcanza copias que pares autorizados ya obtuvieron. Esos pares todavía tienen los datos, y sus nodos tienen las mismas vulnerabilidades. La divulgación les pide que bloqueen el repositorio también.
Finalmente, detener la siembra no deshace la exposición previa. Los datos que ya se hayan sincronizado a través de la red deben considerarse divulgados.
Lo que se ve afectado
Ambos fallos residen en la capa de transporte del nodo, no en el modelo de datos del repositorio en sí. Los objetos de Git y las referencias firmadas se verifican en la capa de almacenamiento como antes. Un atacante no puede falsificar código ni identidades. La falla de confidencialidad ha estado presente en todas las versiones de Radicle publicadas hasta la fecha.
| Problema | Reportado por | Fecha de reporte |
|---|---|---|
| Vulnerabilidad de transporte en texto plano | Konstantinos Maninakis | 2026-06-24 |
| Falla de autenticación entre pares | cryptocode | 2026-08-12 |
El camino hacia la solución
La resolución implica reemplazar el protocolo de red de Radicle, que actualmente utiliza un protocolo personalizado basado en Noise, con iroh. Esa es una cantidad significativa de trabajo, y explica por qué una solución compatible con versiones anteriores no es factible.
El proyecto indica que se está trabajando en la corrección. La divulgación promete honestidad sobre la situación para que los usuarios puedan evaluar y actuar en consecuencia mientras se trabaja en una resolución.
Nuestra opinión
Esta es una divulgación seria de un proyecto que ha estado generando confianza con los desarrolladores. El hecho de que el equipo haya elegido publicar antes de que una corrección estuviera lista habla de esa confianza. Están informando a los usuarios sobre lo que sucedió, lo que está roto y cuáles son los riesgos, incluso aunque no puedan ofrecer una solución todavía.
La corrección requerirá un aumento importante de la versión. Eso significa que los usuarios que actualicen perderán temporalmente la compatibilidad con los clientes más antiguos. El proyecto no ha dicho cuándo se lanzará la nueva versión, solo que el equipo está trabajando en ella.
Para los repositorios privados, el consejo es simple: deje de usarlos hasta que llegue la actualización. Para los repositorios públicos, el riesgo de fuga de información es menor, pero la recomendación sigue en pie.
La divulgación reconoce que algunos usuarios pueden querer mantener sus repositorios privados en almacenamiento en lugar de eliminarlos por completo. Esa es una posición razonable, especialmente dado que la corrección permitirá una nueva siembra. El proyecto también señala que los usuarios deben tratar cualquier dato que ya se haya sincronizado a través de la red como expuesto.
Esto es un recordatorio de que los sistemas peer-to-peer conllevan riesgos únicos. Cuando está intercambiando datos directamente con otros nodos, importa el camino entre usted. En el caso de Radicle, ese camino no estaba protegido, y el proyecto está pagando el precio ahora.
El equipo ha actuado de manera responsable al divulgar públicamente los problemas y proporcionar a los usuarios una guía clara. El siguiente paso es la corrección, y el proyecto se ha comprometido a trabajar en ella. Hasta entonces, el consejo sigue vigente: no se deben usar los repositorios privados a través de la red.
Material fuente: “Radicle: Divulgación de Vulnerabilidad en el Protocolo de Red,” radicle.dev.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.