Radicle, the peer-to-peer code collaboration platform built on Git, has disclosed two critical vulnerabilities in its network protocol. The project warns that all versions released to date are affected, and there is no patch yet. The flaws let attackers read private repository data in transit and impersonate other nodes, and fixing them will break compatibility with older software.
The disclosure comes with a blunt recommendation: stop using private repositories until a fix ships. The project says it is working on a resolution, but the nature of the problem means a full rewrite of the underlying networking code is required. That rewrite will force a major version bump, meaning older clients will stop working with newer servers and vice versa.
“With this disclosure, our goal is, first and foremost, to be honest and clear about the situation, so that users can assess and act accordingly, while we are working on a resolution.”
The Two Flaws
Radicle nodes talk to each other using a custom networking protocol. The first flaw is that this traffic is sent in plain text, which means anyone listening on the network path between two nodes can read everything being exchanged. Konstantinos Maninakis reported this issue on 2026-06-24, and wrote about it at his personal site.
The second flaw is that the connection handshake fails to properly authenticate nodes. An attacker can connect to a victim’s node and pretend to be someone else, presenting a Node ID that does not belong to them. Private repositories are shared only with allow-listed Node IDs, so an attacker who fakes one of those IDs can fetch a private repository directly, without needing to sit on the network path between the two endpoints.
Cryptocode reported that flaw on 2026-08-12, and the project proposed a fix upstream, which is linked in the disclosure. Both issues are now public.
How the Two Flaws Work Together
The two flaws are most dangerous when used together. An attacker on the network path between two nodes can watch the connection handshake and see the Node IDs at both ends. Those IDs are almost always on the allow-list, because nodes typically sync with people they trust. The attacker can then read whatever is exchanged while they watch, and later use one of the IDs they saw to fetch the entire repository on demand.
The realistic threat, according to the disclosure, is anyone on the path between your node and the node it syncs with. No setting or allow-list protects against them. The attack works even if you have never connected to the attacker before.
What Users Should Do Now
The project recommends three steps:
- Stop using private repositories over the network until the security update is released.
- Stop seeding private repositories, as described below.
- Consider every private repository you have transmitted over the network to another node leaked.
If a repository contained unencrypted credentials, keys, or tokens, the disclosure advises rotating them immediately. The project also warns that additional encrypted transports like Tor, I2P, or other overlay networks or VPN solutions are not sufficient to protect data. They hide network traffic from an attacker along the path, but they do not prevent peer impersonation, and a targeted, sophisticated attack could still lead to exfiltration of the contents of private repositories.
Stopping Seeding
To stop seeding a private repository, users need to change the seeding policy for each individual repository. The disclosure provides a command sequence:
- List the private repositories in storage:
rad ls --private --all - Change the seeding policy to “block”:
rad block <RID> - Optionally, stop the node completely:
rad node stop
The disclosure notes that rad block is preferred over rad unseed, because unseed removes the seeding policy entirely and causes a node to fall back to its default behavior. On a default configuration, unseed is enough, but if the default seeding policy has been changed to “allow”, the node keeps serving the repository anyway. block sets an explicit policy that the node checks first, so it works either way.
What This Does Not Fix
Stopping seeding does not delete your local copy of the repository. The copy stays in the storage directory at $(rad path)/storage/<RID without the rad: prefix>. Removing that directory deletes the repository and every fork of it that you hold. The disclosure advises caution: remove it only if you understand what you are doing.
Stopping seeding also does not reach copies that authorized peers already fetched. Those peers still hold the data, and their nodes have the same flaws. The disclosure asks them to block the repository too.
Finally, stopping seeding does not undo past exposure. Data that has already synced over the network should be treated as disclosed.
What Is Affected
Both flaws live in the node transport layer, not in the repository data model itself. Git objects and signed references are verified at the storage layer as before. An attacker cannot forge code or identities. The confidentiality flaw has been present in every Radicle version released to date.
| Issue | Reported By | Reported Date |
|---|---|---|
| Clear-text transport vulnerability | Konstantinos Maninakis | 2026-06-24 |
| Peer authentication flaw | cryptocode | 2026-08-12 |
The Road to Fixing It
The resolution involves replacing Radicle’s networking protocol, which currently uses a custom protocol based on Noise, with iroh. That is a significant amount of work, and it explains why a backward-compatible fix is not feasible.
The project says work towards the fix is under way. The disclosure promises honesty about the situation so users can assess and act accordingly while a resolution is being worked on.
Our Take
This is a serious disclosure from a project that has been building trust with developers. The fact that the team chose to publish before a fix was ready speaks to that trust. They are telling users what happened, what is broken, and what the risks are, even though they cannot offer a solution yet.
The fix will require a major version bump. That means users who upgrade will temporarily lose compatibility with older clients. The project has not said when the new version will ship, only that the team is working on it.
For private repositories, the advice is simple: stop using them until the update arrives. For public repositories, the risk of information leakage is lower, but the recommendation still stands.
The disclosure acknowledges that some users may want to keep their private repositories in storage rather than deleting them entirely. That is a reasonable position, especially since the fix will allow seeding again. The project also notes that users should treat any data that has already synced over the network as exposed.
This is a reminder that peer-to-peer systems carry unique risks. When you are exchanging data directly with other nodes, the path between you matters. In Radicle’s case, that path was not protected, and the project is paying the price now.
The team has acted responsibly by disclosing the issues publicly and giving users clear guidance. The next step is the fix, and the project has committed to working on it. Until then, the advice holds: private repositories should not be used over the network.
Source material: “Radicle: Disclosure of Vulnerability in the Network Protocol,” radicle.dev.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.