Security Advisory: Network Protocol Vulnerabilities in Radicle

Date: 23.09.2026
Subject: Disclosure of critical flaws in the peer-to-peer transport layer.

Radicle is designed as a local-first, peer-to-peer collaboration stack built atop Git. Recently, two severe security vulnerabilities were identified within the network protocol utilized by Radicle nodes.

🚨 Executive Summary

Because the necessary fix is wire-incompatible and the protocol lacks version negotiation, a backward-compatible patch is impossible. Consequently, the resolution will require a major version bump, resulting in a breaking change.

---

🔍 Detailed Analysis of Vulnerabilities

The security failures reside in the node transport layer, specifically regarding how nodes communicate.

1. Lack of Confidentiality

The protocol fails to provide the expected encryption. Data is transmitted in plain text, meaning any actor capable of monitoring the network path between two nodes can intercept and read the exchanged data.

Reported by: Konstantinos Maninakis on 2026-06-24.
Further Reading: Detailed blog post by Maninakis

2. Broken Peer Authentication

The connection handshake is flawed, allowing for node impersonation. An attacker can connect to a node while spoofing a different Node ID.

Since private repositories are restricted to an "allow-list" of specific Node IDs, an attacker who knows or guesses a valid ID can bypass these restrictions to fetch private data directly.

The "Combined Attack" Vector

While impersonation is difficult in isolation (as allow-lists are private), the two flaws create a synergistic threat:

The Bottom Line: Anyone positioned on the network path between your node and a syncing peer can bypass all allow-list protections.

---

🛠️ Mitigation and Workarounds

We are disclosing this before the patch is ready because subsequent updates cannot "undo" data that has already been exposed.

Immediate Action Items

• Cease all network transmission of private repositories.
• Assume any private repository synced over the network is now public.
• Rotate all secrets (API keys, tokens, passwords) found in leaked repositories.

Technical Steps to Stop Seeding

To prevent your node from leaking private data, follow these steps:

1. Identify private repositories: rad ls --private --all

2. Block seeding for specific repositories:

   rad block <RID>
   

   Note: Use rad block rather than rad unseed. If your default policy is set to allow, rad unseed will simply revert to that default, whereas rad block creates an explicit override.

3. Shut down the node entirely:

   rad node stop
   

Important Caveats

• Local Storage: Blocking seeding does not delete the data. The copy remains at $(rad path)/storage/ <RID> (without the rad: prefix). Only delete this directory if you are certain you no longer need the repository or its forks.
• Existing Copies: This does not revoke access for peers who have already fetched the data.
• Overlay Networks: Using Tor, I2P, or VPNs is not sufficient. While these hide traffic from some path attackers, they do not solve the peer impersonation flaw.

---

🛡️ The Path Forward

What is NOT affected?

The vulnerabilities are limited to the transport layer. The underlying repository data model remains secure:

• Git objects are still verified.
• Signed references are still validated at the storage layer.

The Resolution: Migration to iroh

To resolve these issues, Radicle is replacing its custom Noise-based protocol with iroh, an open-source P2P networking stack based on open standards.

$\text{Current Protocol (Custom/Noise)} \xrightarrow{\text{Migration}} \text{iroh (Open Standards)}$

Benefits of iroh include:

• Robust encryption and authentication.
• Improved NAT traversal for better network resilience.

Warning: This migration is inherently backwards-incompatible. When the update is released, it will cause a network partition, separating nodes running the old protocol from those running the new one.