Radicle discloses two vulnerabilities in its peer-to-peer protocol and asks users to stop sending private repositories over the network

A Radicle user with a private repository has to assume, from 23 September onward, that every private push and fetch that has ever left their node was readable to somebody on the network path. Radicle's maintainers disclosed two vulnerabilities in the node network protocol and said every version released so far is vulnerable to both. The team published the disclosure before a fix is available, and the recommended action is to stop using private repositories over the network until the fixed release ships.

The two flaws combine badly. Konstantinos Maninakis reported on 24 June 2026 that Radicle nodes exchange traffic in plain text, so anyone on the path between two nodes can read what they exchange. cryptocode reported on 12 August 2026 that peer authentication in the connection handshake is broken: an attacker can present a Node ID that is not its own, and private repositories are shared only with allow-listed Node IDs, so an attacker who fakes an allow-listed ID can fetch a private repository directly.

The flaws sit in the transport layer, so signed history still verifies

The problems live in the node transport layer. Git objects and signed references are still verified at the storage layer as before, so an attacker cannot forge code or identities. Confidentiality is the property that is gone, and the confidentiality flaw has been present in every Radicle version released so far.

Radicle says the second flaw is harder to exploit on its own than it sounds: the allow-list is not public, and an attacker who is not on the network path has to guess an allow-listed Node ID before impersonation buys them anything. The two together are the risk to worry about. An attacker on the network path can see the Node IDs at both ends of a connection, and both are normally on the allow-list, so an on-path attacker gets both cleartext access and a valid identity to try later.

What to do today

The workaround has three parts, all documented by the Radicle team. Stop using private repositories over the network until the fix is out. Treat every private repository you have transmitted to another node as leaked, and rotate any credentials or keys that were exposed inside them. Set the seeding policy on each private repository to block using rad block, so your node refuses to serve them regardless of its default policy. The maintainers explicitly recommend rad block over rad unseed, because unseed only clears the per-repository policy and falls back to the node default.

The fix will break the network in half

The resolution is to replace Radicle's current transport, a custom protocol built on Noise, with iroh, an open peer-to-peer networking stack. The team says a backward-compatible mitigation is not possible because there is no protocol version negotiation to hang one on, so the release will bump the major version and the upgraded and non-upgraded clusters will not be able to talk to each other. The trade the maintainers made is to make the break at the network layer only and keep the storage layout compatible, so the upgrade does not force a repository rewrite.

For a team choosing self-hosted git alternatives, this is the story to weigh: two protocol flaws, both reported months ago, are being disclosed before the fix is available because no smaller mitigation was reachable. That sets the earliest date a private-repository workflow on Radicle should be trusted again, which is when the iroh transport ships.

Source

Radicle, Disclosure of Vulnerability in the Network Protocol, 23 September 2026. Konstantinos Maninakis, Radicle cleartext transport vulnerability.