Radicle 1.10.3 and earlier send private repos in cleartext

Radicle, a peer-to-peer network for sharing Git repositories, disclosed on September 23, 2026 that every released version sends network traffic unencrypted. A second flaw lets an attacker pretend to be a trusted peer. Together they mean private repositories synced over Radicle can be read, or taken, by anyone on the network path. No fixed version exists yet.

The Radicle project's disclosure tells users to stop using private repositories over the network immediately. It also says to treat any private data already fetched as compromised.

The two flaws

Radicle nodes talk to each other directly instead of through a central server like GitHub. Each connection starts with a handshake based on Noise, a well-known recipe for setting up encrypted links. The handshake is meant to prove who each side is, then encrypt everything after it.

According to Radicle, neither half works as intended:

Flaw	What goes wrong	Reported
Cleartext transport	Data after the handshake is sent unencrypted	June 24, 2026, by Konstantinos Maninakis
Broken peer authentication	An attacker can pose as an allow-listed peer	August 12, 2026, by cryptocode

An allow list is Radicle's way of limiting a private repository to named peers. The second flaw defeats it. Radicle's post puts the risk plainly: "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."

Where the bug lives

Maninakis, who found the first flaw, published a technical write-up the same day. He traces it to a logic error in a method called Protocol::write. Conditions written for SOCKS5, a common proxy protocol, were reused for the Noise transport. As a result, encryption never switched on after the handshake.

He shows how visible the data is. On a live connection to a production seed node, the first byte after the handshake is the letter "r" of "rad". "Anyone on the network path between two nodes...can read all of it," he writes.

The fault sits in a shared library, not only in Radicle. An open issue in the netservices.rs repository says its NoiseSession code forwards writes straight to the inner connection once the handshake completes. "A party able to observe the connection can read the application payload," the issue says. It also warns that anyone able to alter the stream can bypass authentication entirely.

When a fix arrives

Not yet. Radicle says the fix needs a major version bump, not a patch.

The two sources describe the replacement a little differently. Radicle's post says the custom Noise setup will be replaced with the iroh peer-to-peer stack. Maninakis writes that the unreleased Radicle 2.0 will use QUIC and TLS through rustls, a Rust encryption library. Both agree the change breaks compatibility with the 1.x network, so old and new nodes will not talk to each other.

Maninakis says all releases up to version 1.10.3 are affected. Radicle says all released versions are. Neither source lists a CVE identifier.

What this means for developers

If you host private repositories on Radicle, stop syncing them over the network now. Radicle's post suggests blocking them from seeding with rad block <RID>, using the repository's ID.

Assume anything already synced has been seen. Look through those repositories for secrets such as API keys, tokens and passwords, and rotate them. Radicle's advice is to treat previously fetched private data as compromised, and a key in a Git history counts.

If you must keep syncing, wrap the traffic in a layer you control. Radicle names VPNs, WireGuard and SSH tunnels as mitigations. They add the encryption the protocol is missing.

Public repositories were never secret, so the cleartext flaw matters less for them. The impersonation flaw is still worth tracking, since it undermines who a node believes it is talking to.

Plan for the 2.0 upgrade. Because it breaks compatibility, every node you depend on will need to move at roughly the same time. If you build on the netservices.rs library for your own project, follow issue #48, because the same bug may affect you.