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 25 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 -
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.
2 more of the top 3 · 22 posts in this stretch
-
N
this is, indeed, radical https:// radicle.dev/2026/09/23/disclos ure-of-vulnerability-in-network-protocol.html
-
Well, they at least get some kudos for *admitting* it.
-
-
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 · 3 posts in this stretch
-
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…
-
> 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.
-
-
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, 13h 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 1 site · best of 25 · 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…
-
To answer the questions in "EDIT": Yes, we should definitely fix the website with regards to mentions of private repos until there is a fix. I agree on the "not fit for purpose" comment there. However, please consider the perspective of public repositories as well. In My Humble Opinion (IMHO), that is where the peer-to-peer architecture (that…
-
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…
-
> I still believe Radicle would be the best (F)OSS Github alternative (given the focus on source availability which lacks in all alternatives) That is a very bizarre thing to say given the (at least) 3 other forge implementations that I know of with FLOSS licenses
-
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…
-
Did they bother to put this on the socials? I am pretty certain I did not see this on mastodon. I think I only saw it because their zulip sent out a mail. I doubt that zulip has more users than the socials they announce on the web page.
-
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.
-
90 days is a normal disclosure timeline. Theoretically it gives them time to investigate, confirm, etc, and let high-profile users know about the issue privately. Though in this case I can’t imagine confirmation took too long…
-
> This was reported to us by Konstantinos Maninakis on 2026-06-24. Why did Radicle need 3 months after knowing this fundamental flaw to disclose it?
-
It looks like they were using a dependency to deal with the Noise stuff, trusting that it did the right thing... but it didn't.
-
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…
-
True. In a world of limited (if any) responsibility by virtually everybody who is in a position of power, at least someone took the time to release this statement _before_ releasing the fix. That's uncommon.
-
Interesting. I only had a very superficial look at it in the past, but my first impressions were positive - so this news was all the more surprising to me.
-
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.
-
Whenever I've built anything with its own wire protocol, I've looked at it in Wireshark at some point...