NEWS

Radicle has critical flaw that exposes private repositories in plaintext

Radicle, the peer-to-peer code network, disclosed two network protocol flaws that allow reading private repository data without decoding and impersonating trusted nodes. There is no compatible fix for current versions.

Radicle, a peer-to-peer network for code collaboration that positions itself as a decentralized alternative to GitHub and GitLab, disclosed on September 28, 2026, two critical vulnerabilities in the network protocol that underpins all of its versions released to date. The flaws allow any attacker positioned along the network path to read private repository data in plaintext and impersonate nodes present in allow-lists. Because the protocol has no way to negotiate versions between nodes, there is no way to apply a fix compatible with installations already in production.

The problem was identified by independent engineer Kostis Maninakis inside radicle-node, the daemon responsible for syncing peers on the network. The cause is not weak or broken cryptography: it's an implementation error that simply discards the keys after generating them correctly.

The handshake works, but the keys are discarded

Radicle uses the Noise Protocol Framework with the three-message XK handshake pattern, carried over raw TCP sockets. In this process, initiator and responder exchange ephemeral keys and long-term public keys to derive two symmetric session keys, a step known in cryptography as the "split".

The problem: radicle-node never reads these derived keys after computing them. All subsequent communication, including gossip metadata, routing tables, and raw Git object packets, is dispatched directly over the TCP socket without any encryption.

A traffic capture between two local daemons confirms the problem: post-handshake frames carry no authentication tags or stream cipher.

0000 72 61 64 01 03 41 20 00 7c 32 6d 5e b2 1e ab 5d rad..A .|2m^...]
0010 89 1d 11 64 c8 51 a8 fa 75 c0 2a fd c9 c3 04 0e ...d.Q..u.*.....
0020 52 e0 41 05 06 eb 4f 99 00 00 00 24 50 41 43 4b R.A...O....$PACK

The sequence starts with Radicle's protocol magic byte, followed directly by the header of a Git packfile with no encryption at all. The root cause lies in an architectural divergence, within Heartwood (the Rust repository that implements the protocol), between the stage that assembles the transport and the stage that dispatches the frames: the network state machine processes the Noise handshake normally, but the framing layer simply skips the encryption routines when writing.

The second flaw turns leakage into impersonation

Beyond the plaintext traffic, the connection handshake has an authentication validation flaw: an attacker can forge a connection by presenting a spoofed Node ID associated with a peer that is already on an allow-list.

Combined, the two flaws form a complete attack chain. A passive observer positioned along the network path captures valid Node IDs, which travel in plaintext, and then exploits the authentication flaw to impersonate an authorized peer and pull private repositories directly from seed nodes.

Radicle highlights an important point for anyone assessing the real risk: Git content integrity remains intact, because Git objects are content-addressed and references are cryptographically signed, so an attacker cannot alter data without invalidating signatures. What's compromised is exclusively transport confidentiality, not integrity.

Why a patch can't simply be shipped

The protocol's current design reserves no version negotiation field within the handshake frames. This means it's not possible to insert an encryption layer into the existing wire format without breaking connections and taking down nodes in production. Any incremental fix on top of the current codebase would cause connection failures between versions.

That's why the maintainers' recommendation isn't "wait for the patch": it's to immediately halt any private repository operations over clearnet until a complete architectural overhaul is released.

What to do until the patch ships

Anyone operating private repositories on Radicle should treat every repository cloned, pushed, or seeded over clearnet connections as compromised, and act on two fronts.

  1. Rotate secrets: any token, credential, or production secret that was stored in these repositories needs to be replaced immediately.
  2. Isolate traffic: restrict node operation to isolated overlay networks, using WireGuard tunnels or SSH port forwarding between authorized hosts.
# Tunnels node-to-node replication via SSH forwarding
ssh -N -L 8776:127.0.0.1:8776 seed-node.internal.infra

# Points the local radicle-node to sync via the loopback tunnel
rad node connect 127.0.0.1:8776

A specific warning from the report: pointing the global proxy to Tor exit nodes does not solve the problem, because traffic leaving the exit node goes back to traveling over the public internet in plaintext. Real confidentiality with current versions is only sustainable by running exclusively over authenticated onion services or I2P daemons.

The future is Iroh, and compatibility will be broken on purpose

The maintainers confirmed that the custom Noise transport layer will be completely dropped in favor of Iroh, an open-source peer-to-peer networking stack built on QUIC and TLS. Since current versions have no way to negotiate the protocol, this migration will break network compatibility entirely: when the new major version ships, legacy 1.x series installations and updated nodes will suffer an irreversible network partition between them.

What this means for developers in Brazil

Radicle is adopted mainly by teams looking to escape dependence on a centralized code platform, whether for cost reasons, resilience against outages, or concerns about censorship or content moderation. It's a small project next to GitHub, but it's gaining ground in free software communities and among those experimenting with P2P architectures in Rust.

For those already using Radicle on repositories with any sensitive data, the action is straightforward: stop operating over clearnet now, rotate exposed secrets, and temporarily migrate to an SSH or WireGuard tunnel until the Iroh-based build is available. It's worth following the Heartwood repository on GitHub to know when the Iroh release ships, since the update will require replanning the entire network topology of production nodes.

There's also an architecture lesson here for any team building its own protocol on top of Noise, libp2p, or QUIC: a correct cryptographic handshake protects nothing if the derived keys aren't actually wired into the read and write routines. It's worth checking, in any custom secure transport implementation, whether the output of the negotiation's "split" is actually being used to encrypt and decrypt each frame, and not just computed and discarded.

Translated from the Brazilian Portuguese original · Read the original