Le protocole réseau de Radicle envoie les dépôts privés en clair et laisse usurper l’identité des nœuds
Le 23 septembre 2026, Radicle a révélé que son protocole pair-à-pair — présent dans toutes les versions jamais publiées — transporte les données en clair et accepte l’usurpation d’identité des nœuds dans la poignée de main. Quiconque utilise des dépôts privés doit cesser de les servir et considérer comme divulgué tout ce qui a déjà transité sur le réseau.
23 septembre 2026. Le projet Radicle, la forge de code décentralisée pair-à-pair bâtie sur Git, révèle deux failles critiques dans son protocole réseau. Toutes les versions. Les deux défauts touchent toutes les versions publiées à ce jour. Transport, pas stockage. Ils siègent dans la couche de transport entre nœuds, pas dans le modèle de données : les objets Git et les Signed References restent vérifiés, donc un attaquant ne peut pas falsifier du code ni des identités. Pourquoi c’est important : ce qui est cassé, c’est la confidentialité et l’authentification — et la seule correction possible est une migration cassante, sans rétrocompatibilité.
Deux failles qui se renforcent l’une l’autre
La première faille est simple à décrire : le trafic entre deux nœuds Radicle n’est ni chiffré ni authentifié. Les objets transitent en clair. N’importe quel acteur placé sur le chemin réseau entre deux nœuds qui se synchronisent peut lire tout ce qu’ils échangent. Ce problème a été signalé le 24 juin 2026 par Konstantinos Maninakis, qui en a publié l’analyse sur son blog ; Radicle l’a remonté en amont dans le dépôt netservices.rs de cyphernet-labs.
La seconde faille touche la poignée de main. L’authentification de pair est défectueuse et permet l’usurpation : un attaquant peut se connecter à un nœud en présentant un Node ID qui n’est pas le sien. Or les dépôts privés ne sont partagés qu’avec une liste blanche de Node ID. Un attaquant qui falsifie un identifiant autorisé peut donc récupérer un dépôt privé directement, sans même être sur le chemin réseau. Ce second défaut a été signalé le 12 août 2026 par le chercheur cryptocode, avec une correction proposée en amont dans cyphernet.rs.
Pris séparément, chaque défaut a ses limites. Pour usurper un Node ID autorisé, il faut d’abord le connaître, et la liste blanche n’est pas publique : un attaquant hors du chemin réseau doit deviner. C’est combinés que les deux failles deviennent réellement exploitables. Un attaquant sur le chemin voit les Node ID aux deux extrémités d’une connexion — tous deux normalement présents dans la liste blanche. Il lit ce qui est échangé pendant qu’il observe, puis réutilise un Node ID qu’il a vu pour aspirer l’intégralité du dépôt à la demande.
L’intégrité tient, la confidentialité tombe
Il faut être précis sur ce qui reste sûr, parce que c’est contre-intuitif. La signature des Signed References détecte toujours une modification d’objet en transit. Si un attaquant altère un fichier au passage, le nœud récepteur le voit et rejette l’objet. La menace n’est donc pas l’empoisonnement de code, mais la lecture. Pour un dépôt public, la fuite d’information est secondaire — le contenu est public par définition. Pour un dépôt privé, c’est l’inverse : le chiffrement du transport est précisément la garantie qui s’effondre.
C’est aussi pourquoi les contournements classiques ne suffisent pas. Radicle le dit noir sur blanc dans son avis : passer par Tor, I2P, un VPN ou tout autre réseau superposé ne protège pas. Ces surcouches cachent le trafic à un observateur sur le chemin, ce qui réduit la surface d’attaque, mais elles n’empêchent pas l’usurpation de pair. Une attaque ciblée et sophistiquée peut quand même conduire à l’exfiltration du contenu d’un dépôt privé. La menace réaliste, c’est quiconque se trouve sur le chemin entre votre nœud et celui avec lequel il se synchronise — et aucun réglage ni liste blanche ne protège contre elle.
Ce qu’il faut faire maintenant
Le correctif n’existe pas encore, et Radicle publie volontairement l’avis avant lui : aucun correctif ultérieur ne peut annuler une exposition qui a déjà eu lieu. Les consignes sont donc défensives, immédiates et sans ambiguïté.
Cesser de servir les dépôts privés. La commande rad block <RID> pose un blocage explicite sur un dépôt, plus sûr que rad unseed : si vous avez changé la politique d’ensemencement par défaut de block vers allow, un unseed laisse votre nœud continuer à servir le dépôt, alors qu’un block est vérifié en premier.
# Lister les dépôts privés en stockage
rad ls --private --all
# Bloquer explicitement l’ensemencement de chaque dépôt privé
rad block <RID>
# Ou arrêter complètement le nœud
rad node stopConsidérer comme divulgué tout ce qui a transité. Chaque dépôt privé déjà synchronisé sur le réseau doit être traité comme exposé. S’il contenait des identifiants, des clés ou des jetons non chiffrés, il faut les faire tourner.
Prévenir les pairs autorisés. Le blocage n’atteint pas les copies déjà récupérées par les pairs : leurs nœuds portent les mêmes défauts. Il faut leur demander de bloquer le dépôt à leur tour. Et le blocage n’efface pas votre copie locale — elle reste dans $(rad path)/storage/, ce qui est souhaitable si vous voulez reprendre l’ensemencement une fois la version corrigée sortie.
Une migration cassante, et ce qu’elle dit du design
La raison pour laquelle il n’y a pas de correctif rétrocompatible tient à l’absence de négociation de version dans le protocole actuel : la correction est incompatible sur le fil, donc il faut casser. Radicle annonce remplacer son protocole réseau — aujourd’hui un protocole maison bâti sur Noise — par iroh, une pile réseau pair-à-pair open source construite sur des standards ouverts. Au-delà des failles, iroh apporte la traversée de NAT, ce qui améliore la fiabilité et la résilience du réseau.
Cette bascule partitionnera le réseau en deux grappes qui ne peuvent plus se parler : les nœuds migrés et les nœuds non migrés. Le projet s’efforce de limiter la casse au réseau, en conservant la disposition du stockage pour adoucir la montée de version. C’est le prix d’une décision de conception prise à l’origine : ne pas négocier de version de protocole revient à se condamner à une rupture nette le jour où le protocole doit changer.
Verdict
Si vous hébergez des dépôts privés sur Radicle, cessez immédiatement de les ensemencer — rad block sur chacun —, faites tourner tous les secrets qu’ils contiennent et considérez tout ce qui a déjà synchronisé comme divulgué : aucun correctif futur ne remontera le temps. Si vous synchronisez les dépôts privés d’autrui, appliquez la même consigne et prévenez les autres pairs, car leurs nœuds sont tout aussi vulnérables que le vôtre. Si vous n’utilisez Radicle que pour du code public, le risque est faible — l’intégrité des objets est préservée par les Signed References — mais surveillez l’annonce de la version majeure, car la migration vers iroh vous obligera à mettre à jour pour rester connecté au réseau. La leçon dépasse Radicle : un protocole pair-à-pair sans chiffrement ni négociation de version ne se répare pas, il se remplace.