Radicle: Disclosure of Vulnerability in the Network Protocol

Radicle is a peer-to-peer, local-first code collaboration stack built on Git.

Summary

What happened?

Two critical security vulnerabilities in the network protocol used by Radicle nodes were reported.

Which versions are affected?

All versions of Radicle that were released to date are vulnerable.

What is the issue?

Network traffic between nodes is not encrypted and not authenticated. Authentication of repository contents via Signed References still detects if attackers along the network path between two nodes modify objects in transit. Thus, the main concern is information leakage, i.e., attackers along the network path between two nodes reading objects in transit. For public repositories, information leakage is less of a concern. However, encryption in transit is crucial for private repositories.

What should users do?

We recommend to stop using private repositories until a fix is released.

When will the fixed version be released?

Due to a lack of version negotiation features, combined with the fix being incompatible on the wire, a backward compatible mitigation is not feasible; that means the release to fix this issue will be breaking, thus bump the major version number. Work towards this is under way. 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 vulnerabilities

1. 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. This was reported to us by Konstantinos Maninakis on 2026-06-24. You can read his post about the issue at https://maninak.com/blog/radicle-cleartext-transport-vulnerability/. We reported upstream, see this issue.
2. 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.

The second flaw is harder to exploit on its own than it sounds. To impersonate an allow-listed Node ID, an attacker must first know one. The allow-list is not public, so an attacker who is not on the network path has to guess.

In practice, the two flaws are most useful when they can be exploited together: 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 can read whatever is exchanged while they watch, and can then use a Node ID they saw to fetch the whole repository on demand. The realistic threat is anyone on the path between your node and node it syncs with, and no setting or allow-list protects against them.

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.

Workaround

• Stop using private repositories (over the network) until the security update is released. Stop seeding private repositories, as described below. However, you may want to keep your private repositories in storage, i.e., not delete them entirely, so that you may start seeding them again once a fixed version is released.
• Consider every private repository you have transmitted over the network to another node leaked. If it contained unencrypted credentials, keys, or tokens, rotate them.
• Using additionally encrypted transports, such as Tor, I2P, or other overlay networks or VPN solutions are not sufficient to protect your data. They hide network traffic from an attacker along the network path between two nodes. Even though that limits the attack surface, this does not prevent peer impersonation, and a targeted, sophisticated attack might lead to exfiltratation of the contents of private repositories.

How to stop seeding private repositories

List the private repositories in storage:

rad ls --private --all

Change the seeding policy of very individual repository to “block”:

rad block <RID>

Note: We recommend to use rad block instead of rad unseed, in case the seeding policy of your node is set to allow.

rad unseed removes the seeding policy for a repository, and your node then falls back to its default policy. The default is block, so on a default configuration rad unseed is enough. If you changed the default seeding policy to allow, your node keeps serving the repository after you unseed it. rad block sets an explicit block, which the node checks first, so it works either way.

To stop the node completely:

rad node stop

Three limits on what this achieves:

• It stops your node from serving the repository. It does not delete your local copy. The copy stays in $(rad path)/storage/<RID without the rad: prefix>. Remove that directory only if you understand you are deleting the repository and every fork of it that you hold. If in doubt, do not delete from storage.
• It does not reach copies that authorized peers already fetched. Those peers still hold the data, and their nodes have the same flaws. Ask them to block the repository too.
• It does not undo past exposure. Data that has already synced over the network should be treated as disclosed.

What is affected

Both flaws are in the node transport layer, not in the repository data model. 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.

Resolution

We are actively working on a resolution.

The resolution involves replacing Radicle’s networking protocol (currently a custom protocol using Noise) with iroh, an open source peer-to-peer networking stack built on open standards. We already shared out plans to migrate, and the vulnerabilities have given us all the more reason to move forward with this. Beyond addressing the vulnerabilities, iroh brings additional features like NAT traversal which improve the reliability and resilience of the Radicle network.

Such a change to the network transport is by its nature backwards-incompatible. As such, it causes the network to partition into the upgraded and non-upgraded clusters that can not communicate with each other.

Even though this means a major release, we are working to make the upgrade path as smooth as possible, by focusing breakage on the network end, keeping storage layout compatible.

Acknowledgements

We would like to thank Konstantinos Maninakis and cryptocode for responsibly disclosing these vulnerabilities to us and staying in touch.

If you would like to report a security issue, please refer to https://radicle.dev/.well-known/security.txt.