Radicle: Disclosure of Vulnerability in the Network Protocol
66 points by tuxes
66 points by tuxes
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?
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 using it and moved on. This kind of thing is validating that vibe, and will definitely keep me from going back to it.
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.
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 established during key exchange are there and just never used.
The first one is understandable but the second one just blows me away.
EDIT: And why is the vulnerable version still available? Why are they still telling you to install and try out the product on the home page? By definition it is not fit for purpose.
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 Radicle is built on) is the natural fit: hosting Free/Libre and/or Open Source Software (FLOSS).
Public repositories is the main use case we have been seeing Radicle being used for and the one we have been focusing most of our efforts on and we are not aware of any vulnerability affecting that.
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?
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…
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…
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 caught this with a simple tcpdump. But we're all humans and make mistakes. I, too, naively trusted that all of Radicle's comms were encrypted as described in their documentation. I, too, could have run tcpdump and noticed the obvious.
I would hope that as they work on migrating to iroh, they learn from this and perform testing to ensure encrypted comms. But that migration, as discussed in the disclosure, is a comms-breaking change. The entire Radicle world will need to migrate (at around the same time? I'm not sure.)
Whenever I've built anything with its own wire protocol, I've looked at it in Wireshark at some point...
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.
https://maninak.com/blog/radicle-cleartext-transport-vulnerability/
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.
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.
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.
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
Wow, this is hella disturbing! Didn't they rewrite the protocol 3 times from scratch? And now they:
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 source availability which lacks in all alternatives)... I just hope this is gonna end in a "any publicity is good publicity" kind of incident!
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
I think they mean a focus on redundancy and resilience (so availability in the CIA-trifecta sense)
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.