Radicle published two critical flaws before it had a fix, on purpose
Victoria Shinder2 min readThe Radicle peer-to-peer code-collaboration project disclosed two critical vulnerabilities in the network protocol its nodes speak, reported by LWN on 23 September 2026.
The first is that the protocol, in the project's own words, "does not give the confidentiality it was expected to give" — anyone who can observe the network between two nodes can read what they exchange. The second is that peer authentication is broken and allows impersonation: an attacker can spoof their Node ID.
Separately each is bad. Together they compose into the actual attack, and the project spells it out: an attacker on the path sees the Node IDs at both ends of a connection, and both are normally on the allow-list. That attacker reads whatever passes while they watch, then uses a Node ID they saw to fetch the whole repository on demand, including private ones. The stated threat model is anyone on the network path, and no setting or allow-list defends against it.
The disclosure carries its own justification for arriving early:
"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."
Workarounds usable today are in the project's post; a backward-incompatible major update is under way.
The part worth noticing
Publishing without a fix is the right call here, and the reasoning is transportable. The usual argument for waiting is that disclosure arms attackers before defenders can act. That argument depends on the fix being the only defence. Here it is not: the exposure is confidentiality of data already sent, and a patch shipped next month does nothing about traffic observed last week. When the harm is retrospective, silence protects nobody but the project's reputation.
The first comment under the LWN piece goes at exactly that, and it is the uncomfortable half of the story: the project is said to have known for three months, shipping four releases in that window without mentioning it. If that holds, then the sentence about acting today reads differently — it is true, and it was equally true in June.
For anyone running a node the practical read is narrow: treat every repository that node has synced as potentially read by whoever sits on its network path, apply the workarounds now, and plan for a breaking upgrade rather than a patch.