Radicle jusqu'à 1.10.3 envoie les dépôts privés en clair

Radicle, un réseau pair à pair pour partager des dépôts Git, a révélé le 23 septembre 2026 que toutes ses versions publiées envoient le trafic réseau sans chiffrement. Une seconde faille permet à un attaquant de se faire passer pour un pair de confiance. Ensemble, elles signifient que les dépôts privés synchronisés via Radicle peuvent être lus, ou récupérés, par quiconque se trouve sur le chemin réseau. Aucune version corrigée n'existe encore.

La divulgation du projet Radicle demande aux utilisateurs d'arrêter immédiatement d'utiliser des dépôts privés sur le réseau. Elle demande aussi de considérer comme compromises les données privées déjà récupérées.

Les deux failles

Les nœuds Radicle communiquent directement entre eux, sans serveur central comme GitHub. Chaque connexion commence par une poignée de main fondée sur Noise, une méthode reconnue pour établir des liaisons chiffrées. Cette poignée de main doit prouver l'identité de chaque partie, puis chiffrer tout ce qui suit.

Selon Radicle, aucune des deux moitiés ne fonctionne comme prévu :

Faille	Ce qui ne va pas	Signalée
Transport en clair	Les données après la poignée de main partent sans chiffrement	24 juin 2026, par Konstantinos Maninakis
Authentification des pairs cassée	Un attaquant peut se faire passer pour un pair de la liste d'autorisation	12 août 2026, par cryptocode

Une liste d'autorisation est le moyen qu'a Radicle de limiter un dépôt privé à des pairs désignés. La seconde faille la contourne. Le billet de Radicle décrit le risque sans détour : "La menace réaliste, c'est n'importe qui sur le chemin entre votre nœud et le nœud avec lequel il se synchronise, et aucun réglage ni aucune liste d'autorisation ne protège contre eux."

Où se trouve le bogue

Maninakis, qui a trouvé la première faille, a publié une analyse technique le même jour. Il la rattache à une erreur de logique dans une méthode appelée Protocol::write. Des conditions écrites pour SOCKS5, un protocole de proxy courant, ont été réutilisées pour le transport Noise. Résultat : le chiffrement ne s'activait jamais après la poignée de main.

Il montre à quel point les données sont visibles. Sur une connexion réelle vers un nœud seed de production, le premier octet après la poignée de main est la lettre "r" de "rad". "N'importe qui sur le chemin réseau entre deux nœuds...peut tout lire", écrit-il.

Le défaut se trouve dans une bibliothèque partagée, pas seulement dans Radicle. Une issue ouverte dans le dépôt netservices.rs indique que le code NoiseSession transmet les écritures directement à la connexion interne une fois la poignée de main terminée. "Une partie capable d'observer la connexion peut lire les données de l'application", dit l'issue. Elle avertit aussi que quiconque peut modifier le flux peut contourner entièrement l'authentification.

Quand arrivera un correctif

Pas encore. Radicle indique que le correctif exige un changement de version majeure, pas un simple patch.

Les deux sources décrivent le remplacement un peu différemment. Le billet de Radicle dit que la configuration Noise maison sera remplacée par la pile pair à pair iroh. Maninakis écrit que Radicle 2.0, non encore publié, utilisera QUIC et TLS via rustls, une bibliothèque de chiffrement en Rust. Les deux s'accordent sur le fait que le changement casse la compatibilité avec le réseau 1.x. Anciens et nouveaux nœuds ne pourront donc pas communiquer.

Selon Maninakis, toutes les versions jusqu'à 1.10.3 sont touchées. Selon Radicle, toutes les versions publiées le sont. Aucune des sources ne donne d'identifiant CVE.

Ce que cela signifie pour les développeurs

Si vous hébergez des dépôts privés sur Radicle, arrêtez dès maintenant de les synchroniser sur le réseau. Le billet de Radicle propose de les bloquer au seeding avec rad block <RID>, en utilisant l'identifiant du dépôt.

Partez du principe que tout ce qui a déjà été synchronisé a été vu. Cherchez dans ces dépôts des secrets comme des clés d'API, des jetons et des mots de passe, et renouvelez-les. Radicle conseille de traiter les données privées déjà récupérées comme compromises, et une clé dans un historique Git en fait partie.

Si vous devez continuer à synchroniser, enveloppez le trafic dans une couche que vous contrôlez. Radicle cite les VPN, WireGuard et les tunnels SSH comme mesures d'atténuation. Ils ajoutent le chiffrement qui manque au protocole.

Les dépôts publics n'ont jamais été secrets, donc la faille du transport en clair compte moins pour eux. La faille d'usurpation mérite tout de même d'être suivie, car elle sape la certitude d'un nœud sur l'identité de son interlocuteur.

Préparez la mise à niveau vers 2.0. Comme elle casse la compatibilité, chaque nœud dont vous dépendez devra migrer à peu près en même temps. Si vous utilisez la bibliothèque netservices.rs dans votre propre projet, suivez l'issue #48, car le même bogue peut vous toucher.