Radicle tem falha crítica que expõe repositórios privados em texto puro

A Radicle, rede peer-to-peer para colaboração de código que se apresenta como alternativa descentralizada ao GitHub e ao GitLab, divulgou em 28 de setembro de 2026 duas vulnerabilidades críticas no protocolo de rede que sustenta todas as suas versões lançadas até hoje. As falhas permitem que qualquer atacante no caminho da rede leia dados de repositórios privados em texto puro e se passe por nós presentes em listas de permissão (allow-lists). Como o protocolo não tem como negociar versões entre nós, não existe forma de aplicar uma correção compatível com as instalações já em produção.

O problema foi identificado pelo engenheiro independente Kostis Maninakis dentro do radicle-node, o daemon responsável por sincronizar pares na rede. A causa não está em criptografia fraca ou quebrada: é um erro de implementação que simplesmente joga fora as chaves depois de gerá-las corretamente.

O handshake funciona, mas as chaves são descartadas

A Radicle usa o Noise Protocol Framework com o padrão de handshake XK em três mensagens, trafegado sobre sockets TCP crus. Nesse processo, iniciador e respondedor trocam chaves efêmeras e chaves públicas de longo prazo para derivar duas chaves de sessão simétricas, etapa conhecida em criptografia como "split".

O problema: o radicle-node nunca lê essas chaves derivadas depois de calculá-las. Toda comunicação seguinte, incluindo metadados de gossip, tabelas de roteamento e os pacotes brutos de objetos Git, é despachada diretamente pelo socket TCP sem qualquer criptografia.

Uma captura de tráfego entre dois daemons locais confirma o problema: os frames pós-handshake não carregam tags de autenticação nem cifra de fluxo.

0000 72 61 64 01 03 41 20 00 7c 32 6d 5e b2 1e ab 5d rad..A .|2m^...]
0010 89 1d 11 64 c8 51 a8 fa 75 c0 2a fd c9 c3 04 0e ...d.Q..u.*.....
0020 52 e0 41 05 06 eb 4f 99 00 00 00 24 50 41 43 4b R.A...O....$PACK

A sequência começa com o byte mágico do protocolo Radicle seguido diretamente pelo cabeçalho de um packfile Git sem cifra nenhuma. A causa raiz está numa divergência arquitetural, no Heartwood (o repositório Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) → que implementa o protocolo), entre a etapa que monta o transporte e a etapa que despacha os frames: a máquina de estados de rede processa o handshake Noise normalmente, mas a camada de enquadramento simplesmente ignora as rotinas de criptografia na hora de escrever.

A segunda falha transforma vazamento em personificação

Além do tráfego em texto puro, o handshake de conexão tem uma falha de validação de autenticação: um atacante consegue forjar uma conexão apresentando um Node ID falsificado associado a um par que já está numa lista de permissão.

Combinadas, as duas falhas formam uma cadeia de ataque completa. Um observador passivo no caminho da rede captura Node IDs válidos, que trafegam em texto puro, e em seguida explora a falha de autenticação para se passar por um par autorizado e puxar repositórios privados diretamente dos nós semente (seed nodes).

A Radicle destaca um ponto importante para quem avalia o risco real: a integridade do conteúdo Git permanece intacta, porque objetos Git são endereçados por conteúdo e referências são assinadas criptograficamente, então um atacante não consegue alterar dados sem invalidar assinaturas. O que está comprometido é exclusivamente a confidencialidade do transporte, não a integridade.

Por que não dá para simplesmente lançar um patch

O desenho atual do protocolo não reserva nenhum campo de negociação de versão dentro dos frames de handshake. Isso significa que não é possível inserir uma camada de criptografia no formato de wire existente sem quebrar conexões e derrubar nós em produção. Qualquer correção incremental sobre a base atual causaria falhas de conexão entre versões.

Por isso a recomendação dos mantenedores não é "aguarde o patch": é interromper imediatamente qualquer operação de repositório privado via clearnet até que uma reformulação arquitetural completa seja lançada.

O que fazer até o patch sair

Quem opera repositórios privados na Radicle deve tratar todo repositório clonado, enviado (push) ou semeado (seed) por conexões clearnet como comprometido, e agir em duas frentes.

1. Rotacionar segredos: qualquer token, credencial ou segredo de produção que estava armazenado nesses repositórios precisa ser trocado imediatamente.
2. Isolar o tráfego: restringir a operação dos nós a redes overlay isoladas, usando túneis WireGuard ou encaminhamento de porta via SSH entre hosts autorizados.

# Encapsula a replicação nó-a-nó via encaminhamento SSH
ssh -N -L 8776:127.0.0.1:8776 seed-node.internal.infra

# Aponta o radicle-node local para sincronizar via túnel loopback
rad node connect 127.0.0.1:8776

Um alerta específico do relatório: apontar o proxy global para nós de saída Tor não resolve o problema, porque o tráfego que deixa o nó de saída volta a trafegar pela internet pública em texto puro. Confidencialidade real com as versões atuais só é sustentável rodando exclusivamente sobre serviços onion autenticados ou daemons I2P.

O futuro é Iroh, e a compatibilidade será quebrada de propósito

Os mantenedores confirmaram que a camada de transporte Noise personalizada será completamente abandonada em favor do Iroh, um stack de rede peer-to-peer de código aberto construído sobre QUIC e TLS. Como as versões atuais não têm como negociar protocolo, essa migração vai quebrar a compatibilidade de rede por completo: quando a nova versão major for lançada, instalações legadas da série 1.x e nós atualizados vão sofrer uma partição de rede irreversível entre si.

O que isso significa para quem desenvolve no Brasil

A Radicle é adotada sobretudo por times que querem fugir da dependência de uma plataforma centralizada de código, seja por custo, por resiliência a quedas, seja por preocupação com censura ou moderação de conteúdo. É um projeto pequeno perto do GitHub, mas ganha espaço em comunidades de software livre e em quem experimenta arquiteturas P2P com Rust.

Para quem já usa a Radicle em repositórios com qualquer dado sensível, a ação é direta: parar de operar via clearnet agora, rotacionar segredos expostos e migrar temporariamente para túnel SSH ou WireGuard até que a base em Iroh esteja disponível. Vale acompanhar o repositório Heartwood no GitHub para saber quando o release com Iroh sai, já que a atualização vai exigir replanejar toda a topologia de rede dos nós em produção.

Há também uma lição de arquitetura que vale para qualquer time construindo protocolo próprio sobre Noise, libp2p ou QUIC: um handshake criptográfico correto não protege nada se as chaves derivadas não forem efetivamente conectadas às rotinas de leitura e escrita. Vale a pena revisar, em qualquer implementação própria de transporte seguro, se a saída do "split" da negociação está de fato sendo usada para cifrar e decifrar cada frame, e não apenas calculada e descartada.

Fonte: InfoQ