Radicle admite dos fallas críticas: claves y tokens en riesgo

Radicle confirma dos fallas críticas en su protocolo de red: qué está en juego

Radicle publicó este 23 de septiembre una divulgación de seguridad que no admite matices: dos vulnerabilidades críticas afectan a su protocolo de red y a todas las versiones del stack distribuidas hasta la fecha. Lo que empezó como una revisión interna escaló a una disclosure pública y completa de las fallas, anticipándose al lanzamiento del parche.

La plataforma de Radicle es peer-to-peer, "local-first" y está construida sobre Git. En su disclosure, la organización describe un escenario específico: cualquier observador en la ruta de red entre dos nodos puede leer el tráfico en texto plano y, además, suplantar el Node ID de un par para descargar repositorios privados completos. Aunque los objetos firmados (Signed References) siguen garantizando que el contenido no se modifica en tránsito, la confidencialidad prometida por la herramienta nunca existió.

Las dos fallas, en concreto

La disclosure detalla dos puntos débiles complementarios, divulgados por dos investigadores externos:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Confidencialidad rota en el transporte: cualquier actor con visibilidad del camino entre dos nodos puede leer el tráfico. Reportada el 24 de junio de 2026 por Konstantinos Maninakis (maninak.com/blog/radicle-cleartext-transport-vulnerability).
Autenticación rota en el handshake: un atacante puede presentar un Node ID falso. Si ese ID forma parte de la allow-list de un repositorio privado, puede descargarlo sin siquiera estar en la ruta de red. Reportada el 12 de agosto de 2026 por el investigador conocido como cryptocode.

El vector realista es la combinación de ambas: un atacante en la ruta observa los Node IDs de ambos extremos (ambos suelen estar allow-listed), lee lo que se transmite, y luego reaprovecha un ID capturado para extraer repositorios completos on-demand. La disclosure lo resume de forma directa: no hay ajuste ni allow-list que proteja frente a un observador en el camino.

Como apunta LWN.net en su cobertura, la organización decidió publicar antes de tener el parche disponible porque "ningún fix posterior puede deshacer una exposición ya ocurrida" (LWN.net).

Qué hacer hoy si usas Radicle con repos privados

Radicle recomienda tratar como expuesto cualquier repositorio privado que se haya sincronizado por red y aplicar tres acciones inmediatas:

Listar repositorios privados con rad ls --private --all y bloquearlos uno a uno con rad block <RID> (preferible a rad unseed si la política por defecto fue cambiada a allow).
Rotar claves, tokens o credenciales que estuvieran almacenados sin cifrar dentro de esos repos.
Entender que el bloqueo no se propaga: cualquier par autorizado que ya descargó el repositorio mantiene su copia, y sus nodos comparten las mismas fallas.

La disclosure es explícita al descartar que Tor, I2P o una VPN resuelvan el problema: ocultan el tráfico de observadores externos, pero no impiden la suplantación del par, así que un ataque dirigido sigue siendo viable.

La solución técnica implica romper la compatibilidad

Radicle trabaja en sustituir su protocolo de transporte (actualmente un protocolo propio sobre Noise) por iroh, una librería de red peer-to-peer en Rust de N0, Inc. El cambio será incompatible en el cable: cualquier versión antigua y la nueva no se comunicarán entre sí, lo que obliga a una subida de versión mayor y a una partición temporal de la red entre nodos actualizados y no actualizados.

Iroh 1.0 se publicó el 15 de junio de 2026 según TechTimes (TechTimes) como el primer release estable de la librería, tras más de 65 versiones previas y 4 años de desarrollo. Su diferenciador es que cada endpoint se identifica con una clave Ed25519 en lugar de una dirección IP, lo que hace que cada conexión quede mutuamente autenticada y cifrada de extremo a extremo. Iroh usa QUIC con TLS 1.3, logra ~90% de éxito en hole-punching directo y delega el resto a relays sin estado que reportan en torno a ~95% del tráfico directo entre dispositivos.

La elección tiene un objetivo adicional que Radicle detalla en la disclosure: además de cerrar las dos fallas, Iroh aporta NAT traversal (cruzar routers y firewalls sin configurar puertos) y reduce la dependencia de address books manuales, una fricción real en despliegues que el modelo peer-to-peer hereda del stack original.

Qué significa esto para tu startup

Para un founder que use Radicle con repos privados (algo común en configuraciones auto-hospedadas y equipos distribuidos que evitan GitHub por razones de soberanía de datos), esta nota es una instrucción operativa, no una noticia más.

Acciones inmediatas recomendadas:

Audita hoy mismo qué repos privados tu equipo ha sincronizado por la red de Radicle y trátalos como expuestos hasta que se libere la versión con Iroh. Esto incluye cualquier secreto sin cifrar (claves API, tokens de despliegue).
Comunica a tu equipo y a los pares autorizados que también bloqueen sus copias; la protección no se replica sola.
Si necesitas colaboración privada inmediata, evalúa complementarla con GitHub, GitLab self-hosted sobre SSH con claves rotadas, o plataformas con cifrado en tránsito probado hasta que Radicle publique su versión mayor.

Implicación estratégica más amplia: el caso Radicle es un buen recordatorio de que "peer-to-peer" y "seguro por defecto" no son sinónimos. El uso de Signed References de Git cubre integridad, pero no cubre confidencialidad del transporte. Para founders construyendo sobre stacks descentralizados, conviene exigir en cualquier proveedor las mismas tres garantías que ofrece Iroh: autenticación mutua por clave criptográfica, cifrado de extremo a extremo de la capa de transporte y NAT traversal como feature, no como receta casera.