Radicle discloses critical network protocol vulnerabilities affecting all versions
Unencrypted traffic and weak node authentication flaw discovered in peer-to-peer git hosting protocol; fix requires breaking protocol change.
What to know
- Radicle's network protocol has lacked encryption and proper authentication since inception, exposing private repository contents to attackers on the network path between syncing nodes.
- The vulnerability requires a breaking protocol change—replacing the custom Noise implementation with iroh—which will partition the network and require a major version bump with no backward compatibility.
- Radicle disclosed the flaw 91 days after being reported (June 24 to Sept 23), before releasing a fix, but the confidentiality breach has already affected every deployed version.
The dispute Whether Radicle's transparent pre-fix disclosure offsets the severity of the vulnerability and the engineering failures that allowed it to persist undetected for three years. · positions read across 37 posts and comments
The vulnerability reveals serious engineering failures; basic protocol testing (packet inspection) was never performed.
-
“No offense, but how can you build a protocol that accidentally does not encrypt stuff at all? Don't you at some point look at the wires?”
freddyb · Lobsters ↗
Radicle deserves credit for transparent pre-fix disclosure, which is uncommon industry practice.
-
“Well, they at least get some kudos for *admitting* it.”
retr0id · Lobsters ↗
The breaking protocol change and network partition may be fatal to Radicle's adoption; recovery will be very difficult.
-
“This seems like death; I'm not sure how they can recover from this.”
veqq · Lobsters ↗
Radicle Decentralized git hosting platformKonstantinos Maninakis Security researcher
How it unfolded 4 developments, newest first · click a bar or a number to jump articlespostscomments
-
4
Mixed assessmentCautious credit for transparency, skepticism about recovery
While some commenters acknowledged Radicle's decision to disclose before releasing a fix as commendable, others questioned the project's viability. One commenter called the situation 'death' for private repository use. A separate technical analysis showed session keys were established but never used for encryption.
“Well, they at least get some kudos for *admitting* it.”
— retr0id -
Well, they at least get some kudos for *admitting* it.
2 more of the top 3 · 32 posts in this stretch
-
Radicle has been one of those projects that had seemed interesting, but something always bothered me about it. (I think it was very highly tied to the cryptocurrency movement for a while? And the Cyphernet GitHub org seems to have rebranded from a DAO?)This, unfortunately, kinda seals the deal on never using this thing, at least not for anything I…
-
N
this is, indeed, radical https:// radicle.dev/2026/09/23/disclos ure-of-vulnerability-in-network-protocol.html
-
-
3
Technical community questions protocol design and testing practices
Developers and security professionals expressed alarm at the fundamental nature of the flaw—an entire protocol lacking encryption despite using Noise. Comments focused on the absence of basic verification like packet inspection (Wireshark) and questioned how this escaped testing for 3+ years.
“No offense, but how can you build a protocol that accidentally does not encrypt stuff at all? Don't you at some point look at the wires?”
— freddyb -
No offense, but how can you build a protocol that accidentally does not encrypt stuff at all? Don't you at some point look at the wires? Re-implement the protocol as a different clients - for tests?
2 more of the top 3 · 5 posts in this stretch
-
>This was reported to us by Konstantinos Maninakis on 2026-06-24.announcement 3 months later is not super great, considering that the current advice is "Stop using private repositories (over the network) until the security update is released."
-
Yeah, I think your tone is entirely valid. I've poked at Radicle in the past, and I love what it in theory is doing, but it...I dunno how to put this, but after being in the industry for so long, you kind of get a feel for something being *off* in a project? I'd have a hell of a time articulating what I was noticing, but it was enough I stopped…
-
-
1
Radicle announces major version bump and protocol migration plan
Due to lack of version negotiation and backward-incompatible fixes needed, Radicle announced a major version bump. The fix involves replacing the custom Noise protocol with iroh, an open-source peer-to-peer stack, requiring a breaking network change that will partition upgraded and non-upgraded clusters.
“The resolution involves replacing Radicle's networking protocol (currently a custom protocol using Noise) with iroh, an open source peer-to-peer networking stack built on open standards.”
— Radicle -
2
Radicle discloses network protocol vulnerabilities publicly
Radicle publicly disclosed two critical vulnerabilities: unencrypted network traffic between nodes and weak node authentication. The vulnerabilities expose private repository contents to attackers on the network path. Radicle published the disclosure before releasing a fix, stating that no fix can undo exposures that have already occurred.
“We are publishing this before the security update is available. You can act on it today, and no fix we release later can undo an exposure that has already happened.”
— Radicle -
first by HN Frontpage, 15h ago
-
-
background
Konstantinos Maninakis reports vulnerabilities to Radicle — Security researcher Konstantinos Maninakis discovered and reported two critical flaws in Radicle's network protocol to the team.
What people are saying 18 voices from 2 sites · best of 37 · verbatim
- Why did Radicle take 91 days (June 24 to September 23) to disclose after learning of the vulnerability?
- How can users ensure their private repositories were not compromised during the window of exposure?
- Will the network partition from the breaking protocol change cause a permanent split in the Radicle ecosystem?
- Yesterday
-
Overall, i feel like it may be important to recognize the value of the tool that they are building while also acknowledging the serious security flaws presented here. Echoing, one of the other commenters at the end of the day, we are all humans, and we're going to make mistakes. Personally I think this is one of those mistakes that really isn't…
-
It's tough with this requiring a fix that breaks the existing on-wire communications protocol. The Radicle network has grown pretty substantially over the past few months, so it takes a bit of juggling to get all the right pieces in all the right places for all the right people. I do think during early development, it would have been good to have…
-
I think they mean a focus on redundancy and resilience (so availability in the CIA-trifecta sense)
-
90days usually also gives you time to fix… here they say: > Which versions are affected? > > All versions of Radicle that were released to date are vulnerable. Between the time of the initial report and now, there were several releases. So in addition of being really bad, it seems like low priority for them to fix…
-
Wow, this is hella disturbing! Didn't they rewrite the protocol 3 times *from scratch*? And now they: - apparently have *no versioning*?? ("Due to a lack of version negotiation features") - No encryption?? A real bummer! From a high-level architectural view I still believe Radicle would be the best (F)OSS Github alternative (given the focus on…
-
> The network protocol used by Radicle does not give the confidentiality it was expected to give. Anyone who can observe the network path between two nodes can read the data they exchange as the data is sent in plain text.Is this a... design choice? This feels like too egregious of an omission to be a regular vulnerability here.
-
But…I mean. You write a custom wire protocol and don’t once in 3+ years look at a pcap? It’s just really weird to me.
-
Glad to hear they are moving to iroh instead of a custom protocol. This is the problem with rolling your own stuff.As a bonus, this should help camouflage the traffic. (Iroh is becoming more common.)
-
I was wondering how you get from "custom protocol using Noise" to "network traffic between nodes is not encrypted". Turns out it's fairly simple: they didn't encrypt anything after the initial handshake.
-
Holy poop. Reading the article I thought it was a flaw in the encryption or key exchange or something, such that traffic was “encrypted but not really.” Like you could trivially derive the session keys or something but the traffic was protected against casual inspection. Now reading the bug reports it would appear that, no, the session keys…
-
Reading the blog, it sounds more like they were depending on libraries (both by Cyphernet, interestingly) and implicitly trusting them, instead of verifying.Which I can understand to an extent with large, high-traffic dependencies but these were really low traffic projects with like 10 stars on github and barely any development... Well, hindsight…
-
admitting that there's a fundamental security issue with your software that can't be fixed in near future is... probably one of the worst possible results of a vuln disclosure
-
I keep seeing [Iroh](https://iroh.computer/) show up in re-decentralising projects. (e.g. Delta Chat, Radicle. I guess it's time to learn how its protocol is different than tailscale, libp2p, ipfs, cjdns, yggdrasil, and all the wormhole variants.
-
> What is the issue?> Network traffic between nodes is not encrypted and not authenticated.Oh.After all of the work they put into using cryptographic identities and decentralization tricks, how did they forget to do anything about the network traffic?Was this a case of thinking they'd handle it later, but then it fell off the TODO list?
-
The fact that this was reported three months ago and the "workaround" is to stop using private repos and assume they are all pwnd is quite something. How do you not notice that cross-node traffic is not encrypted when building something like this?
-
This whole project reads like amateur hour. Still using curl pipe to shell install and everything. Plus this lax security disclosure with just an outstandingly foolish security flaw. Gross.
-
> We recommend to stop using private repositories until a fix is released. This seems like death; I'm not sure how they can recover from this.
-
My main wish is if radicle had a way to make issues online, without installing the software. Runing a piece of software is a high barrier of entry to make a bug report, which the entire reason I use codeberg instead.