> 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?
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 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?
I think the core problem isn't that the Noise "API" is confusing, it's that Noise is a framework for building reasonably-secure protocols. If you don't know how to build or evaluate cryptosystems, you shouldn't assume that just dropping in a library will somehow make your novel network protocol secure.
"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.)
>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."
"Transport Encryption & Privacy:
Connections between peers in the Radicle network are encrypted using a Noise protocol handshake. [...] After the handshake phase is completed, all data exchanged between peers is fully encrypted and benefits from strong forward secrecy, ensuring secure and private communications across the network."
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?
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 intend to keep private. This isn't about proficiency in some protocol which has XYZ footgun: they never checked that payloads were encrypted. Ridiculous.
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.
It's a team of 3. It's not like they have a security team, dedicated testers. They were for very long releasing beta software. That in fact already worked.
Oh, so when they advertise “Your Data, Forever and Secure”[1] in big bold letters on their homepage with total disregard for the truth of that statement they are just committing fraud. Got it.
> 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.
Oh indeed, if we just redefine words in the fine print then we can commit fraud with impunity.
Please enlighten me how that blurb supports the common reading of the claim: Your data, … secure. Note that and is a additive conjunction, so the components can be safely examined separately.
A regular person would assume that means your data is secure against tampering and disclosure. If you then say: “lol, jk we do not do anything related to securing your data” in the fine print then in a reasonable society you should be required to remove that more prominent false large print.
You can always go back and reword your large print to be more accurate without making deceptive claims to your benefit. Weird how the deception is always beneficial.
Security is an umbrella term. You can't just assume that secure things are private--you have to make the determination in context with whatever kind of thing it is.
The primary goals of a system like radicle are:
- spread the word
- don't let anybody alter it
If you ask if it's secure, you should assume you'll get an answer related to those purposes.
If you got a sunburn while standing in line for a water slide, you wouldn't say that the slide is unsafe, even though being burned is a hell of a departure from "safety". You'd have to be a little more specific.
all of these start with “unauthorized access” to define this term. can you please explain how open access to private repositories is not unauthorized access and how you can’t expect your data moving to private repositories to be private?
> Information security's primary focus is the balanced protection of data confidentiality, integrity, and availability
..and radicle.dev does nothing to suggest confidentiality is a focus. Words like "private" or "encrypted" don't appear on their front page.
When I saw this, I was surprised because I didn't even know they supported private repos. I just don't understand why you'd want private repositories on a peer to peer protocol. The whole point is to get away from all of the problematic things that stem from having a single point of control/failure and the hierarchies that follow therefrom. Private repositories means that you're re-implementing the very problems that you're presumably using something like Radicle to get away from, now at the application layer instead. If you can tolerate having an admin that may later be unavailable or untrustworthy such that you're locked out, why not just use github?
It's like private blog posts on wordpress. Yeah, if the feature is in there it should work but projects like these encapsulate a certain perspective, and if they're run by a small number of technologists who clearly in it because they care, then I think it's reasonable to evaluate their success based on whether they address the primary problem they're up against, not whether they have a bug in some feature they tacked on as an afterthought.
Anybody can set up encryption on a link. Shame on them for forgetting to do that, but radicle has much more ambitious goals. If they need more help than they're getting for some of the mundane stuff, well I'm not going to judge them too harshly for that.
It should appear as encrypted iroh traffic. Depending on how radicle handles things, this could make it difficult to identify versus other applications using iroh. If needed, they could add noise or dummy traffic in the future for further obfuscation.
They may be overselling, but I’ve had good experiences using apps built on it.
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.
That's a downside of all decentralised software, isn't it? If there's a convenient access point, that access point is also a point of centralisation. To be distributed, you have to be running the software yourself. The big problem is that the software always ends up being inconvenient. People have no problem using bittorrent because the software is actually usable.
> If there's a convenient access point, that access point is also a point of centralisation
I don't think that's true. Bitcoin and Ethereum are very decentralized but most casual users don't run a node and do everything with a gateway. ATProto/Bluesky is the same.
What they have in common is shared global state, using a blockchain or PLC. That means everyone gets a full view of the network (outside of censoring relays) and user account are portable. You can go with a commercial provider for convenience but always have the option of self hosting if they raise prices or censor you.
That option is more important than the share or users who self host right now.
Ethereum is an interesting case for this, because there's a default node address in Metamask, and that's obviously the one that most people are using. It also costs money, forcing enshittification.
Not sure about bitcoin - I run my own node for that (as I said, running the software). If you have a light client I think you have to have your own server?
Look at IPFS though. Extremely slow to access files but since everyone used ipfs.io gateway which cached all files ever accessed, nobody noticed the underlying decentralised system actually sucked.
My main wish is a way to search the repositories on a node. Or a way to have tags. The whole network is like a blackbox of projects unless you can get an outside link.
> 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.
Is there a risk that other projects that may be using the same cyphernet-labs/netservices.rs code, like Nym & Farcaster, have also been expecting authentication & encryption where it hasn't been happening?
Honestly issues like this crop up pretty commonly. JWT alg:none for example. Or even older people forcing SSL to downgrade to encryption null.
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.
I was very surprised when I realized what defaults postgres uses when it comes to SSL. I can see how people consider it a pragmatic choice - but still...
> 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.
I find this to be very telling about what kind of people they are. If you make a mistake this big you need to own up to it. BS all you want, maybe you think that works for you.. but people see through it.
Just use mTLS via QUIC, it’s standardized, secure, future proof and has implementations in tons of languages and supports proper certificate checks and that whole ecosystem around it which they apparently tried to reinvent. It’s such a great protocol for these use cases, I don’t get why it’s not used more.
I don't think the consumer ecosystem is mature yet.
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.
I don't see how mTLS would work for Radicle or other decentralized systems because, as far as I understand, both parties need to have their certificates signed by a shared root.
> 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?
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 is 20/20.
Do you mean this blog post? https://maninak.com/blog/radicle-cleartext-transport-vulnera...
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?
That is the article of the reporter.
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...)
Correct, I was referring to the original linked article/disclosure.
I think the core problem isn't that the Noise "API" is confusing, it's that Noise is a framework for building reasonably-secure protocols. If you don't know how to build or evaluate cryptosystems, you shouldn't assume that just dropping in a library will somehow make your novel network protocol secure.
"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.)
yes
>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."
Also: user guide still mentions supporting private repositories [0]
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...
[1] https://radicle.dev/faq
Thank you for noticing. We need to fix that.
Also https://radicle.dev/guides/protocol#transport-encryption--pr...
"Transport Encryption & Privacy: Connections between peers in the Radicle network are encrypted using a Noise protocol handshake. [...] After the handshake phase is completed, all data exchanged between peers is fully encrypted and benefits from strong forward secrecy, ensuring secure and private communications across the network."
I was floored that they emailed me about it for the first time today saying "of course you already know all the details from the blog post".
Me: "No!"
For the record, that is not what the Zulip announcement wrote. Please don't kick us when we're down.
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?
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 intend to keep private. This isn't about proficiency in some protocol which has XYZ footgun: they never checked that payloads were encrypted. Ridiculous.
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.
It's a team of 3. It's not like they have a security team, dedicated testers. They were for very long releasing beta software. That in fact already worked.
If a core feature of your software requires security guarantees you can't just say they don't have a "security team" .
Oh, so when they advertise “Your Data, Forever and Secure”[1] in big bold letters on their homepage with total disregard for the truth of that statement they are just committing fraud. Got it.
[1] https://radicle.dev/
The rest of that quote is:
> 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.
Oh indeed, if we just redefine words in the fine print then we can commit fraud with impunity.
Please enlighten me how that blurb supports the common reading of the claim: Your data, … secure. Note that and is a additive conjunction, so the components can be safely examined separately.
A regular person would assume that means your data is secure against tampering and disclosure. If you then say: “lol, jk we do not do anything related to securing your data” in the fine print then in a reasonable society you should be required to remove that more prominent false large print.
You can always go back and reword your large print to be more accurate without making deceptive claims to your benefit. Weird how the deception is always beneficial.
Security is an umbrella term. You can't just assume that secure things are private--you have to make the determination in context with whatever kind of thing it is.
The primary goals of a system like radicle are:
- spread the word
- don't let anybody alter it
If you ask if it's secure, you should assume you'll get an answer related to those purposes.
If you got a sunburn while standing in line for a water slide, you wouldn't say that the slide is unsafe, even though being burned is a hell of a departure from "safety". You'd have to be a little more specific.
https://www.ibm.com/think/topics/data-security
https://www.fortinet.com/resources/cyberglossary/data-securi...
https://en.wikipedia.org/wiki/Data_security
https://www.nccoe.nist.gov/data-security
etc
all of these start with “unauthorized access” to define this term. can you please explain how open access to private repositories is not unauthorized access and how you can’t expect your data moving to private repositories to be private?
https://en.wikipedia.org/wiki/Information_security#Key_conce... says this:
> Information security's primary focus is the balanced protection of data confidentiality, integrity, and availability
..and radicle.dev does nothing to suggest confidentiality is a focus. Words like "private" or "encrypted" don't appear on their front page.
When I saw this, I was surprised because I didn't even know they supported private repos. I just don't understand why you'd want private repositories on a peer to peer protocol. The whole point is to get away from all of the problematic things that stem from having a single point of control/failure and the hierarchies that follow therefrom. Private repositories means that you're re-implementing the very problems that you're presumably using something like Radicle to get away from, now at the application layer instead. If you can tolerate having an admin that may later be unavailable or untrustworthy such that you're locked out, why not just use github?
It's like private blog posts on wordpress. Yeah, if the feature is in there it should work but projects like these encapsulate a certain perspective, and if they're run by a small number of technologists who clearly in it because they care, then I think it's reasonable to evaluate their success based on whether they address the primary problem they're up against, not whether they have a bug in some feature they tacked on as an afterthought.
Anybody can set up encryption on a link. Shame on them for forgetting to do that, but radicle has much more ambitious goals. If they need more help than they're getting for some of the mundane stuff, well I'm not going to judge them too harshly for that.
Could be a solo person or a team of 5,000. This is amateur hour, and they are not serious about their purported secure and private platform.
To be fair even the largest companies are still using curl piped to sh in their Linux install instructions. And they are all fucking imbeciles.
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.)
>this should help camouflage the traffic
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.
It should appear as encrypted iroh traffic. Depending on how radicle handles things, this could make it difficult to identify versus other applications using iroh. If needed, they could add noise or dummy traffic in the future for further obfuscation.
They may be overselling, but I’ve had good experiences using apps built on it.
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.
That's a downside of all decentralised software, isn't it? If there's a convenient access point, that access point is also a point of centralisation. To be distributed, you have to be running the software yourself. The big problem is that the software always ends up being inconvenient. People have no problem using bittorrent because the software is actually usable.
> If there's a convenient access point, that access point is also a point of centralisation
I don't think that's true. Bitcoin and Ethereum are very decentralized but most casual users don't run a node and do everything with a gateway. ATProto/Bluesky is the same.
What they have in common is shared global state, using a blockchain or PLC. That means everyone gets a full view of the network (outside of censoring relays) and user account are portable. You can go with a commercial provider for convenience but always have the option of self hosting if they raise prices or censor you.
That option is more important than the share or users who self host right now.
Ethereum is an interesting case for this, because there's a default node address in Metamask, and that's obviously the one that most people are using. It also costs money, forcing enshittification.
Not sure about bitcoin - I run my own node for that (as I said, running the software). If you have a light client I think you have to have your own server?
Look at IPFS though. Extremely slow to access files but since everyone used ipfs.io gateway which cached all files ever accessed, nobody noticed the underlying decentralised system actually sucked.
Like onion/ipfs/many others, I'd expect gateways to pop up if it grows relatively popular. If LLM scrapers don't destroy them immediately, at least.
They have public repositories on GitHub.
https://github.com/radicle-dev
My main wish is a way to search the repositories on a node. Or a way to have tags. The whole network is like a blackbox of projects unless you can get an outside link.
If the node runs an HTTP API (radicle-httpd) backed by an indexer (radicle-search), you can.
Try https://radicle.network/explore and set index.radicle.garden as your search seed.
https://stats.radicle.at/repos
Thanks this is exactly what I was needing.
We have a prototype demonstrating writes from the web:
https://radicle.zulipchat.com/#narrow/channel/369278-Explore...
This is definitely on our radar.
> 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.
Is there a risk that other projects that may be using the same cyphernet-labs/netservices.rs code, like Nym & Farcaster, have also been expecting authentication & encryption where it hasn't been happening?
I honestly thought there would be some elaborate chain there, not "we forgot to use encryption"...
Honestly issues like this crop up pretty commonly. JWT alg:none for example. Or even older people forcing SSL to downgrade to encryption null.
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.
I was very surprised when I realized what defaults postgres uses when it comes to SSL. I can see how people consider it a pragmatic choice - but still...
And not using authentication.
> 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.
I find this to be very telling about what kind of people they are. If you make a mistake this big you need to own up to it. BS all you want, maybe you think that works for you.. but people see through it.
As someone who joined the project at the beginning of the year, I can assure you that the team cares a lot. Hindsight is always 20/20.
We will work hard to regain the trust of the community.
exactly!
They probably forgot to tell Claude to make no mistakes.
But seriously, the fact that this started as Crypto-adjacent should have immediately disqualified them for serious use.
Just use mTLS via QUIC, it’s standardized, secure, future proof and has implementations in tons of languages and supports proper certificate checks and that whole ecosystem around it which they apparently tried to reinvent. It’s such a great protocol for these use cases, I don’t get why it’s not used more.
I don't think the consumer ecosystem is mature yet.
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.
I don't see how mTLS would work for Radicle or other decentralized systems because, as far as I understand, both parties need to have their certificates signed by a shared root.
I really don't see the point of private repositories on Radicle. Just use wireguard.
thankfully (for me), this is about the git forge and not the oss calendar and contact synchronization software by the same name
https://radicale.org/v3.html
it's not the same name
you're right! i can't believe i only noticed that just now, thanks!
Idiots