Radicle, die Peer-to-Peer-Code-Kollaborationsplattform, die auf Git basiert, hat zwei kritische Schwachstellen in ihrem Netzwerkprotokoll aufgedeckt. Das Projekt warnt, dass alle bis dato veröffentlichten Versionen betroffen sind und es noch keinen Patch gibt. Die Fehler ermöglichen es Angreifern, private Repository-Daten während der Übertragung auszulesen und andere Knoten zu imitieren, und ihre Behebung wird die Kompatibilität mit älterer Software beeinträchtigen.
Die Offenlegung kommt mit einer deutlichen Empfehlung: die Nutzung privater Repositories sollte bis zur Verfügbarkeit einer Lösung eingestellt werden. Das Projekt teilt mit, dass es an einer Lösung arbeitet, aber die Art des Problems erfordert eine vollständige Überarbeitung des zugrunde liegenden Netzwerkcodes. Diese Überarbeitung wird zu einem größeren Versionssprung führen, was bedeutet, dass ältere Clients nicht mehr mit neueren Servern und umgekehrt funktionieren werden.
„Mit dieser Offenlegung ist es unser Ziel, in erster Linie ehrlich und transparent über die Situation zu sein, damit Benutzer die Lage einschätzen und entsprechend handeln können, während wir an einer Lösung arbeiten.“
Die Zwei Fehler
Radicle-Knoten kommunizieren miteinander über ein benutzerdefiniertes Netzwerkprotokoll. Der erste Fehler besteht darin, dass dieser Datenverkehr im Klartext übertragen wird, was bedeutet, dass jeder, der den Netzwerkpfad zwischen zwei Knoten abhört, alles auslesen kann, was ausgetauscht wird. Konstantinos Maninakis meldete dieses Problem am 2026-06-24 und schrieb darüber auf seiner persönlichen Website.
Der zweite Fehler besteht darin, dass das Verbindungs-Handshake keine ordnungsgemäße Authentifizierung von Knoten durchführt. Ein Angreifer kann sich mit einem Opferknoten verbinden und so tun, als wäre er jemand anderes, indem er eine Node-ID präsentiert, die ihm nicht gehört. Private Repositories werden nur mit Nodes mit einer Allow-List geteilt, sodass ein Angreifer, der eine dieser IDs fälscht, ein privates Repository direkt abrufen kann, ohne sich auf dem Netzwerkpfad zwischen den beiden Endpunkten positionieren zu müssen.
Cryptocode meldete diesen Fehler am 2026-08-12, und das Projekt schlug eine Lösung vor, die im Disclosure verlinkt ist. Beide Probleme sind nun öffentlich.
Wie die Zwei Fehler Zusammenwirken
Die beiden Schwachstellen sind am gefährlichsten, wenn sie zusammen verwendet werden. Ein Angreifer auf dem Netzwerkpfad zwischen zwei Knoten kann das Verbindungs-Handshake beobachten und die Node-IDs an beiden Enden sehen. Diese IDs stehen fast immer auf der Zulassungsliste, da Knoten in der Regel mit Personen synchronisieren, denen sie vertrauen. Der Angreifer kann dann alles lesen, was ausgetauscht wird, während er zusieht, und später eine der IDs, die er gesehen hat, verwenden, um das gesamte Repository auf Anfrage abzurufen.
Die realistische Bedrohung, so die Offenlegung, ist jeder auf dem Pfad zwischen Ihrem Knoten und dem Knoten, mit dem er synchronisiert. Keine Einstellung oder Zulassungsliste schützt davor. Der Angriff funktioniert auch dann, wenn Sie noch nie eine Verbindung zu dem Angreifer hergestellt haben.
Was Nutzer jetzt tun sollten
Das Projekt empfiehlt drei Schritte:
- Verwenden Sie private Repositories über das Netzwerk nicht mehr, bis das Sicherheitsupdate veröffentlicht ist.
- Beenden Sie das Seeding von privaten Repositories, wie unten beschrieben.
- Gehen Sie davon aus, dass jedes private Repository, das Sie über das Netzwerk an einen anderen Knoten gesendet haben, kompromittiert wurde.
Wenn ein Repository unverschlüsselte Anmeldeinformationen, Schlüssel oder Token enthielt, wird empfohlen, diese gemäß der Offenlegung sofort zu rotieren. Das Projekt warnt außerdem, dass zusätzliche verschlüsselte Transportprotokolle wie Tor, I2P oder andere Overlay-Netzwerke oder VPN-Lösungen nicht ausreichen, um Daten zu schützen. Sie verbergen den Netzwerkverkehr vor einem Angreifer auf dem Pfad, verhindern aber nicht die Peer-Identitätsverschleierung, und ein gezielter, ausgeklügelter Angriff könnte dennoch zur Exfiltration des Inhalts privater Repositories führen.
Seeding beenden
Um das Seeding eines privaten Repository zu beenden, müssen Benutzer die Seeding-Richtlinie für jedes einzelne Repository ändern. Die Offenlegung bietet eine Befehlsequenz:
- List the private repositories in storage:
rad ls --private --all - Change the seeding policy to „block“:
rad block <RID> - Optionally, stop the node completely:
rad node stop
The disclosure notes that rad block is preferred over rad unseed, because unseed removes the seeding policy entirely and causes a node to fall back to its default behavior. On a default configuration, unseed is enough, but if the default seeding policy has been changed to „allow“, the node keeps serving the repository anyway. block sets an explicit policy that the node checks first, so it works either way.
Was dies nicht behebt
Stopping seeding does not delete your local copy of the repository. The copy stays in the storage directory at $(rad path)/storage/<RID without the rad: prefix>. Removing that directory deletes the repository and every fork of it that you hold. The disclosure advises caution: remove it only if you understand what you are doing.
Das Beenden des Seeding erreicht auch nicht Kopien, die autorisierte Peers bereits abgerufen haben. Diese Peers haben die Daten weiterhin vorliegen, und ihre Knoten haben die gleichen Schwachstellen. Die Offenlegung bittet sie, auch das Repository zu blockieren.
Letztendlich macht das Beenden des Seedings vergangene Expositionen nicht rückgängig. Daten, die bereits über das Netzwerk synchronisiert wurden, sollten als offengelegt betrachtet werden.
Was betroffen ist
Beide Schwachstellen liegen in der Knotentransportebene, nicht im Repository-Datenmodell selbst. Git-Objekte und signierte Referenzen werden wie zuvor auf der Speicherebene verifiziert. Ein Angreifer kann keinen Code oder Identitäten fälschen. Die Vertraulichkeitslücke ist in jeder Radicle-Version vorhanden, die bis heute veröffentlicht wurde.
| Problem | Gemeldet von | Meldedatum |
|---|---|---|
| Klartext-Transport-Schwachstelle | Konstantinos Maninakis | 2026-06-24 |
| Peer-Authentifizierungsfehler | cryptocode | 2026-08-12 |
Der Weg zur Behebung
Die Lösung besteht darin, Radicles Netzwerkprotokoll zu ersetzen, das derzeit ein benutzerdefiniertes Protokoll verwendet, das auf Noise basiert, durch iroh. Das ist eine erhebliche Menge Arbeit, und es erklärt, warum eine abwärtskompatible Lösung nicht praktikabel ist.
Das Projekt teilt mit, dass die Arbeit an der Behebung des Problems bereits im Gange ist. Die Offenlegung verspricht Ehrlichkeit über die Situation, damit Benutzer die Lage einschätzen und entsprechend handeln können, während eine Lösung entwickelt wird.
Unsere Einschätzung
Dies ist eine ernste Offenlegung von einem Projekt, das bei Entwicklern Vertrauen aufgebaut hat. Die Tatsache, dass das Team sich entschieden hat, zu veröffentlichen, bevor eine Lösung bereit war, spricht für dieses Vertrauen. Sie informieren Benutzer darüber, was passiert ist, was defekt ist und welche Risiken bestehen, obwohl sie noch keine Lösung anbieten können.
Die Behebung erfordert ein großes Versions-Update. Das bedeutet, dass Benutzer, die aktualisieren, vorübergehend die Kompatibilität mit älteren Clients verlieren werden. Das Projekt hat noch keine Auslieferungszeit für die neue Version genannt, nur dass das Team daran arbeitet.
Für private Repositories ist der Rat einfach: Verwenden Sie diese nicht, bis das Update eintrifft. Bei öffentlichen Repositories ist das Risiko von Datenlecks geringer, aber die Empfehlung gilt dennoch.
Die Offenlegung räumt ein, dass einige Benutzer ihre privaten Repositories lieber in der Speicherung belassen möchten, anstatt sie vollständig zu löschen. Das ist eine vernünftige Position, insbesondere da die Behebung die erneute Saatgutausgabe ermöglicht. Das Projekt weist außerdem darauf hin, dass Benutzer alle Daten, die bereits über das Netzwerk synchronisiert wurden, als offengelegt betrachten sollten.
Dies ist eine Erinnerung daran, dass Peer-to-Peer-Systeme einzigartige Risiken bergen. Wenn Sie Daten direkt mit anderen Knoten austauschen, ist der Weg zwischen Ihnen wichtig. Im Fall von Radicle war dieser Weg nicht geschützt, und das Projekt zahlt jetzt dafür.
Das Team hat verantwortungsbewusst gehandelt, indem es die Probleme öffentlich bekannt gemacht und Benutzern klare Anweisungen gegeben hat. Der nächste Schritt ist die Behebung, und das Projekt hat sich verpflichtet, daran zu arbeiten. Bis dahin gilt der Rat: private Repositories sollten nicht über das Netzwerk verwendet werden.
Quelle: „Radicle: Disclosure of Vulnerability in the Network Protocol“, radicle.dev.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.