Radicle até 1.10.3 envia repositórios privados sem criptografia

O Radicle, uma rede ponto a ponto para compartilhar repositórios Git, revelou em 23 de setembro de 2026 que todas as versões lançadas enviam o tráfego de rede sem criptografia. Uma segunda falha deixa um atacante se passar por um par confiável. Juntas, elas significam que repositórios privados sincronizados pelo Radicle podem ser lidos, ou levados, por qualquer um no caminho da rede. Ainda não existe versão corrigida.

A divulgação do projeto Radicle pede que os usuários parem imediatamente de usar repositórios privados pela rede. Também pede que dados privados já baixados sejam tratados como comprometidos.

As duas falhas

Os nós do Radicle conversam diretamente entre si, sem um servidor central como o GitHub. Cada conexão começa com um handshake baseado no Noise, um método conhecido para montar conexões criptografadas. O handshake deve provar quem é cada lado e depois criptografar tudo o que vem em seguida.

Segundo o Radicle, nenhuma das duas metades funciona como deveria:

Falha	O que dá errado	Relatada
Transporte sem criptografia	Os dados após o handshake saem sem criptografia	24 de junho de 2026, por Konstantinos Maninakis
Autenticação de pares quebrada	Um atacante pode se passar por um par da lista de permissão	12 de agosto de 2026, por cryptocode

A lista de permissão é o jeito do Radicle de limitar um repositório privado a pares específicos. A segunda falha a anula. O texto do Radicle descreve o risco sem rodeios: "A ameaça realista é qualquer um no caminho entre o seu nó e o nó com que ele sincroniza, e nenhuma configuração ou lista de permissão protege contra eles."

Onde está o bug

Maninakis, que encontrou a primeira falha, publicou uma análise técnica no mesmo dia. Ele a atribui a um erro de lógica em um método chamado Protocol::write. Condições escritas para o SOCKS5, um protocolo de proxy comum, foram reaproveitadas no transporte Noise. Com isso, a criptografia nunca era ativada depois do handshake.

Ele mostra como os dados ficam visíveis. Em uma conexão real a um nó seed de produção, o primeiro byte após o handshake é a letra "r" de "rad". "Qualquer um no caminho da rede entre dois nós...pode ler tudo", escreve.

O defeito está em uma biblioteca compartilhada, não só no Radicle. Uma issue aberta no repositório netservices.rs diz que o código de NoiseSession repassa as escritas direto para a conexão interna quando o handshake termina. "Quem consegue observar a conexão pode ler os dados da aplicação", diz a issue. Ela também alerta que qualquer um capaz de alterar o fluxo pode contornar a autenticação por completo.

Quando chega a correção

Ainda não. O Radicle diz que a correção exige subir a versão principal, não um patch.

As duas fontes descrevem a substituição de forma um pouco diferente. O texto do Radicle diz que a configuração própria do Noise será trocada pela pilha ponto a ponto iroh. Maninakis escreve que o Radicle 2.0, ainda não lançado, usará QUIC e TLS via rustls, uma biblioteca de criptografia em Rust. As duas concordam que a mudança quebra a compatibilidade com a rede 1.x. Ou seja, nós antigos e novos não vão se comunicar.

Maninakis diz que todas as versões até a 1.10.3 são afetadas. O Radicle diz que todas as versões lançadas são. Nenhuma das fontes informa um identificador CVE.

O que isso significa para desenvolvedores

Se você hospeda repositórios privados no Radicle, pare de sincronizá-los pela rede agora. O texto do Radicle sugere bloqueá-los da distribuição com rad block <RID>, usando o ID do repositório.

Considere que tudo o que já foi sincronizado foi visto. Procure nesses repositórios segredos como chaves de API, tokens e senhas, e troque-os. O conselho do Radicle é tratar dados privados já baixados como comprometidos, e uma chave no histórico do Git conta.

Se você precisa continuar sincronizando, envolva o tráfego em uma camada que você controla. O Radicle cita VPNs, WireGuard e túneis SSH como mitigações. Eles acrescentam a criptografia que falta ao protocolo.

Repositórios públicos nunca foram secretos, então a falha de transporte sem criptografia pesa menos para eles. Ainda assim, vale acompanhar a falha de personificação, porque ela mina a certeza de um nó sobre com quem está falando.

Planeje a atualização para a 2.0. Como ela quebra a compatibilidade, todos os nós de que você depende vão precisar migrar mais ou menos ao mesmo tempo. Se você usa a biblioteca netservices.rs no seu próprio projeto, acompanhe a issue #48, porque o mesmo bug pode afetar você.