> 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?
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 is 20/20.
It's unfortunate that write-up is AI generated ("Here's the catch... And this is the part that honestly surprised me" tipped me off, and Pangram cites it as 100% AI too), because it's hard to understand what's happening.
It looks like the Noise API can be confusing. They tried to implement it, got the handshake and key exchange right, but then used Noise API calls intended for sending raw data directly to the wire without the encryption they set up? So keys were exchanged, then never used?
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."
FAQ still says that "Radicle supports private repositories [...] completely invisible to the rest of the network" [1]
[0] https://radicle.dev/guides/user#initializing-a-private-repos...
Me: "No!"
This, unfortunately, kinda seals the deal on never using this thing, at least not for anything I intend to keep private. This isn't about proficiency in some protocol which has XYZ footgun: they never checked that payloads were encrypted. Ridiculous.
Is this a... design choice? This feels like too egregious of an omission to be a regular vulnerability here.
As a bonus, this should help camouflage the traffic. (Iroh is becoming more common.)
How? QUIC is easy to fingerprint and flow classificate:
https://datatracker.ietf.org/doc/html/rfc9000#section-12.1
Speaking of bold claims, Iroh, just like Radicle, are overselling themselves:
>iroh's QUIC multipath implementation automatically switches between Wi-Fi, cellular, ethernet, LAN, LoRa, HaLow, Tor, Bluetooth—or bring your own transport.
The thing is, QUIC multipath isn't standardized.
They may be overselling, but I’ve had good experiences using apps built on it.
Try https://radicle.network/explore and set index.radicle.garden as your search seed.
Adding a cert to my Android phone was a huge pain in the ass. Most homelab apps like Jellyfin don't support it. The homelab space is so buck broken it assumes i don't have a public IP address to just expose things without going through the convoluted VPN setup.
> Peer authentication in the connection handshake is broken and allows impersonation. An attacker can connect to your node and present a Node ID that is not its own. Private repositories are shared only with allow-listed Node IDs. An attacker who fakes an allow-listed Node ID can fetch a private repository directly, without being on the network path. This was reported to us by cryptocode on 2026-08-12. We proposed a fix upstream, see this pull request.
They are trying to sweet write it as much as possible. But basically there is neither encryption nor authentication. The person who made the protocol/program simply didn't care.
In any system that provides security it should only be designed to run if the security is in use, and to fail immediately with no further action if the security is not used.
But seriously, the fact that this started as Crypto-adjacent should have immediately disqualified them for serious use.
> All social artifacts are stored in Git, and signed using public-key cryptography. Radicle verifies the authenticity and authorship of all data for you.
They're clearly not talking about privacy there.
Is it embarrassing that their private feature was broken? Sure. But it's for the most part a publishing platform. Protecting users against a network adversary who wan't to know what they're publishing isn't exactly core functionality.
"Don't roll your own crypto" gets a lot of lip service (and a fair number of eye rolls) but it's really, truly something worth considering because it isn't just the algorithms or libraries you choose: it's about the whole package, including things like wire serialization, internal handshakes/security, etc. Just grabbing a Noise tutorial and building your own implementation is a Bad. Idea.
And this is only getting worse now that people can prompt their way through building a "secure" system only to realize they really didn't understand what that means. No amount of Markdown saying, "don't introduce a cryptographic vulnerability in this code" is going to save you if you don't know what to do in the first place.
But also: the vulnerability was literally visible using basic Wireshark/pcap traffic sniffing. I'm sorry, but if you don't even bother (or know how) to do that kind of basic security analysis you should stop and look for someone who does to check your system in the real world before you tell people to depend on it for serious work.
(That being said, if someone had just typed 'find me a vulnerability in this protocol' in a code agent backed by Fable or Astra with any kind of access to network traffic dumps it probably would have taken about 15 minutes to discover this issue. Might even be significant part of how the above author found it, given the other LLM-ish fingerprints in the writeup.)
I believe the blog post being referred to here is the one linked to in the title (i.e. https://radicle.dev/2026/09/23/disclosure-of-vulnerability-i...)