Radicle bis 1.10.3 sendet private Repos im Klartext

Radicle, ein Peer-to-Peer-Netz zum Teilen von Git-Repositories, hat am 23. September 2026 offengelegt, dass jede veröffentlichte Version den Netzwerkverkehr unverschlüsselt sendet. Eine zweite Schwachstelle lässt einen Angreifer sich als vertrauenswürdigen Peer ausgeben. Zusammen bedeutet das: Private Repositories, die über Radicle synchronisiert werden, kann jeder auf dem Netzwerkpfad lesen oder abgreifen. Eine korrigierte Version gibt es noch nicht.

Die Offenlegung des Radicle-Projekts fordert Nutzer auf, private Repositories sofort nicht mehr über das Netz zu verwenden. Bereits abgerufene private Daten sollen als kompromittiert gelten.

Die zwei Schwachstellen

Radicle-Knoten sprechen direkt miteinander statt über einen zentralen Server wie GitHub. Jede Verbindung beginnt mit einem Handshake auf Basis von Noise, einem bekannten Verfahren zum Aufbau verschlüsselter Verbindungen. Der Handshake soll beweisen, wer jede Seite ist, und danach alles verschlüsseln.

Laut Radicle funktioniert keine der beiden Hälften wie gedacht:

Schwachstelle	Was schiefgeht	Gemeldet
Klartext-Übertragung	Daten nach dem Handshake gehen unverschlüsselt raus	24. Juni 2026, von Konstantinos Maninakis
Defekte Peer-Authentifizierung	Ein Angreifer kann sich als Peer auf der Erlaubnisliste ausgeben	12. August 2026, von cryptocode

Eine Erlaubnisliste ist Radicles Weg, ein privates Repository auf benannte Peers zu beschränken. Die zweite Schwachstelle hebelt sie aus. Radicles Beitrag benennt das Risiko klar: "Die realistische Bedrohung ist jeder auf dem Pfad zwischen Ihrem Knoten und dem Knoten, mit dem er synchronisiert, und keine Einstellung und keine Erlaubnisliste schützt dagegen."

Wo der Fehler steckt

Maninakis, der die erste Schwachstelle fand, veröffentlichte am selben Tag eine technische Analyse. Er führt sie auf einen Logikfehler in einer Methode namens Protocol::write zurück. Bedingungen, die für SOCKS5 geschrieben waren, ein verbreitetes Proxy-Protokoll, wurden für den Noise-Transport wiederverwendet. Dadurch schaltete sich die Verschlüsselung nach dem Handshake nie ein.

Er zeigt, wie sichtbar die Daten sind. Auf einer echten Verbindung zu einem produktiven Seed-Knoten ist das erste Byte nach dem Handshake der Buchstabe "r" von "rad". "Jeder auf dem Netzwerkpfad zwischen zwei Knoten...kann alles davon lesen", schreibt er.

Der Fehler steckt in einer gemeinsam genutzten Bibliothek, nicht nur in Radicle. Ein offenes Issue im Repository netservices.rs sagt, dass der NoiseSession-Code Schreibvorgänge nach abgeschlossenem Handshake direkt an die innere Verbindung weiterreicht. "Wer die Verbindung beobachten kann, kann die Anwendungsdaten lesen", heißt es im Issue. Es warnt auch, dass jeder, der den Datenstrom verändern kann, die Authentifizierung vollständig umgehen kann.

Wann ein Fix kommt

Noch nicht. Radicle sagt, die Korrektur erfordere einen Sprung der Hauptversion, keinen Patch.

Die beiden Quellen beschreiben den Ersatz etwas unterschiedlich. Radicles Beitrag sagt, das eigene Noise-Setup werde durch den Peer-to-Peer-Stack iroh ersetzt. Maninakis schreibt, das unveröffentlichte Radicle 2.0 werde QUIC und TLS über rustls nutzen, eine Rust-Bibliothek für Verschlüsselung. Beide sind sich einig, dass die Änderung die Kompatibilität mit dem 1.x-Netz bricht. Alte und neue Knoten werden also nicht miteinander sprechen.

Maninakis sagt, alle Versionen bis 1.10.3 seien betroffen. Radicle sagt, alle veröffentlichten Versionen seien es. Keine der Quellen nennt eine CVE-Kennung.

Was das für Entwickler bedeutet

Wenn Sie private Repositories auf Radicle hosten, hören Sie jetzt auf, sie über das Netz zu synchronisieren. Radicles Beitrag schlägt vor, sie mit rad block <RID> vom Seeding auszuschließen, mit der ID des Repositories.

Gehen Sie davon aus, dass alles bereits Synchronisierte gesehen wurde. Durchsuchen Sie diese Repositories nach Geheimnissen wie API-Schlüsseln, Tokens und Passwörtern und tauschen Sie sie aus. Radicle rät, bereits abgerufene private Daten als kompromittiert zu behandeln, und ein Schlüssel in einer Git-Historie zählt dazu.

Wenn Sie weiter synchronisieren müssen, packen Sie den Verkehr in eine Schicht, die Sie kontrollieren. Radicle nennt VPNs, WireGuard und SSH-Tunnel als Gegenmaßnahmen. Sie liefern die Verschlüsselung, die dem Protokoll fehlt.

Öffentliche Repositories waren nie geheim, daher wiegt die Klartext-Schwachstelle für sie weniger. Die Schwachstelle beim Identitätsnachweis sollten Sie dennoch verfolgen, denn sie untergräbt, mit wem ein Knoten zu sprechen glaubt.

Planen Sie das Upgrade auf 2.0. Weil es die Kompatibilität bricht, muss jeder Knoten, auf den Sie angewiesen sind, ungefähr gleichzeitig umziehen. Wenn Sie die Bibliothek netservices.rs in einem eigenen Projekt nutzen, verfolgen Sie Issue #48, denn derselbe Fehler kann Sie betreffen.