Bekendmaking van kwetsbaarheid in het netwerkprotocol

Datum: 23-09-2026

Samenvatting

Wat is er gebeurd? Er zijn twee kritieke beveiligingskwetsbaarheden gemeld in het netwerkprotocol dat door Radicle-nodes wordt gebruikt.

Welke versies zijn getroffen? Alle tot op heden uitgebrachte versies van Radicle zijn kwetsbaar.

Wat is het probleem? Netwerkverkeer tussen nodes is niet versleuteld en niet geauthenticeerd. De authenticatie van repository-inhoud via Signed References detecteert nog steeds of aanvallers langs het netwerkpad tussen twee nodes objecten tijdens het transport wijzigen.

De belangrijkste zorg is daarom informatielekken: aanvallers langs het netwerkpad tussen twee nodes kunnen objecten tijdens het transport lezen. Voor publieke repositories is dit minder zorgwekkend, maar versleuteling tijdens transport is cruciaal voor private repositories.

Wat moeten gebruikers doen? We raden aan om te stoppen met het gebruik van private repositories totdat er een oplossing is uitgebracht.

Wanneer wordt de herstelde versie uitgebracht? Vanwege een gebrek aan functies voor versienegotiatie, in combinatie met het feit dat de oplossing incompatibel is op netwerkniveau, is een achterwaarts compatibele mitigatie niet haalbaar. Dit betekent dat de release om dit probleem op te lossen een breaking change zal zijn, waardoor het hoofdversienummer (major version) zal stijgen. Er wordt momenteel aan gewerkt.

Met deze bekendmaking is ons doel in de eerste plaats eerlijk en duidelijk te zijn over de situatie, zodat gebruikers dit kunnen inschatten en dienovereenkomstig kunnen handelen terwijl wij werken aan een oplossing.

De kwetsbaarheden

Het netwerkprotocol dat door Radicle wordt gebruikt, biedt niet de vertrouwelijkheid die werd verwacht. Iedereen die het netwerkpad tussen twee nodes kan observeren, kan de gegevens die zij uitwisselen lezen, aangezien de gegevens in platte tekst worden verzonden. Dit werd op 24-06-2026 aan ons gemeld door Konstantinos Maninakis. U kunt zijn bericht over dit probleem lezen op: https://maninak.com/blog/radicle-cleartext-transport-vulnerability/. We hebben dit upstream gemeld.

Daarnaast is de peer-authenticatie in de connectie-handshake defect, wat impersonatie mogelijk maakt. Een aanvaller kan verbinding maken met uw node en een Node ID presenteren dat niet het zijne is. Private repositories worden alleen gedeeld met Node ID's op een allow-list. Een aanvaller die een Node ID van de allow-list vervalst, kan direct een private repository ophalen zonder zich op het netwerkpad te bevinden. Dit werd op 12-08-2026 aan ons gemeld door cryptocode. We hebben een oplossing upstream voorgesteld.

De tweede fout is op zichzelf moeilijker uit te buiten dan het klinkt. Om een Node ID van de allow-list te imiteren, moet een aanvaller er eerst een weten. De allow-list is niet openbaar, dus een aanvaller die niet op het netwerkpad zit, moet gissen.

In de praktijk zijn de twee fouten het meest effectief wanneer ze samen worden uitgebuat: een aanvaller op het pad ziet de Node ID's aan beide uiteinden van een verbinding, en beide staan normaal gesproken op de allow-list. Die aanvaller kan alles lezen wat er wordt uitgewisseld terwijl hij meekijkt, en kan vervolgens een Node ID dat hij heeft gezien gebruiken om de volledige repository op aanvraag op te halen.

De realistische dreiging is iedereen op het pad tussen uw node en de node waarmee deze synchroniseert; geen enkele instelling of allow-list beschermt hiertegen.

We publiceren dit voordat de beveiligingsupdate beschikbaar is. U kunt hier vandaag al op reageren; geen enkele oplossing die we later uitbrengen kan een blootstelling ongedaan maken die al heeft plaatsgevonden.

Tijdelijke oplossing

• Stop met het gebruiken van private repositories (over het netwerk) totdat de beveiligingsupdate is uitgebracht.
• Stop met het seeden van private repositories, zoals hieronder beschreven.

U kunt uw private repositories wel in de opslag behouden (dus niet volledig verwijderen), zodat u ze weer kunt gaan seeden zodra een herstelde versie is uitgebracht.

Ga ervan uit dat elke private repository die u over het netwerk naar een andere node heeft verzonden, is gelekt. Als deze onversleutelde inloggegevens, sleutels of tokens bevatte, dient u deze te vernieuwen (roteren).

Het gebruik van aanvullend versleutelde transportmiddelen, zoals Tor, I2P of andere overlay-netwerken of VPN-oplossingen, is niet voldoende om uw gegevens te beschermen. Deze verbergen het netwerkverkeer voor een aanvaller langs het netwerkpad tussen twee nodes. Hoewel dit het aanvalsoppervlak beperkt, voorkomt het peer-impersonatie niet, en een gerichte, geavanceerde aanval zou kunnen leiden tot exfiltratie van de inhoud van private repositories.

Hoe stop je met het seeden van private repositories

1. Lijst de private repositories in de opslag op:

rad ls --private --all

1. Wijzig het seeding-beleid van elke individuele repository naar "block":

rad block <RID>

Opmerking: We raden aan om rad block te gebruiken in plaats van rad unseed, voor het geval het seeding-beleid van uw node is ingesteld op "allow".

rad unseed verwijdert het seeding-beleid voor een repository, waarna uw node terugvalt op het standaardbeleid. Het standaardbeleid is "block", dus bij een standaardconfiguratie is rad unseed voldoende. Als u het standaard seeding-beleid echter heeft gewijzigd naar "allow", blijft uw node de repository serveren nadat u deze heeft unseeded. rad block stelt een expliciete blokkering in die de node eerst controleert, waardoor het in beide gevallen werkt.

Om de node volledig te stoppen: rad node stop

Er zijn drie beperkingen aan wat dit bereikt:

• Het stopt uw node met het serveren van de repository. Het verwijdert uw lokale kopie niet. De kopie blijft aanwezig in $(rad path)/storage/<RID zonder het rad: prefix>. Verwijder deze map alleen als u begrijpt dat u de repository en elke fork daarvan die u bezit, verwijdert. Bij twijfel: verwijder niets uit de opslag.
• Het bereikt geen kopieën die geautoriseerde peers al hebben opgehaald. Die peers hebben de data nog steeds en hun nodes hebben dezelfde gebreken. Vraag hen om de repository ook te blokkeren.
• Het maakt eerdere blootstelling niet ongedaan. Data die al over het netwerk is gesynchroniseerd, moet als openbaar beschouwd worden.

Wat is er getroffen

Beide fouten bevinden zich in de transportlaag van de node, niet in het datamodel van de repository. Git-objecten en signed references worden zoals voorheen geverifieerd op de opslaglaag. Een aanvaller kan geen code of identiteiten vervalsen.

De fout in de vertrouwelijkheid is aanwezig in elke tot nu toe uitgebrachte versie van Radicle.

Oplossing

We werken actief aan een oplossing.

De oplossing houdt in dat het netwerkprotocol van Radicle (momenteel een aangepast protocol met Noise) wordt vervangen door iroh, een open-source peer-to-peer netwerkstack gebouwd op open standaarden. We hadden onze plannen om te migreren al gedeeld, en deze kwetsbaarheden hebben ons extra reden gegeven om hiermee door te gaan. Naast het aanpakken van de kwetsbaarheden brengt iroh extra functies met zich mee, zoals NAT-traversal, wat de betrouwbaarheid en veerkracht van het Radicle-netwerk verbetert.

Een dergelijke wijziging in het netwerktransport is inherent niet achterwaarts compatibel. Hierdoor zal het netwerk worden opgesplitst in geüpgradede en niet-geüpgradede clusters die niet met elkaar kunnen communiceren.

Hoewel dit een grote release (major release) betekent, werken we eraan om het upgradepad zo soepel mogelijk te maken door de breuk te concentreren op het netwerkeinde en de opslagindeling compatibel te houden.

Erkenningen

We willen Konstantinos Maninakis en cryptocode bedanken voor het verantwoord melden van deze kwetsbaarheden en voor het contact houden.

Als u een beveiligingsprobleem wilt melden, raadpleeg dan https://radicle.dev/.well-known/security.txt.