Radicle: Disclosure of Vulnerability in the Network Protocol

Radicle：网络协议漏洞披露

Radicle is a peer-to-peer, local-first code collaboration stack built on Git. Radicle 是一个基于 Git 构建的对等（peer-to-peer）、本地优先的代码协作栈。

Summary

摘要

What happened? Two critical security vulnerabilities in the network protocol used by Radicle nodes were reported. 发生了什么？ Radicle 节点所使用的网络协议中被报告存在两个严重的安全性漏洞。

Which versions are affected? All versions of Radicle that were released to date are vulnerable. 哪些版本受到影响？ 迄今为止发布的所有 Radicle 版本均存在漏洞。

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. 问题是什么？ 节点间的网络流量既未加密也未经过身份验证。虽然通过“签名引用”（Signed References）进行的仓库内容验证仍然可以检测出网络路径上的攻击者是否篡改了传输中的对象，但主要担忧在于信息泄露，即位于两个节点之间网络路径上的攻击者可以读取传输中的对象。对于公共仓库，信息泄露的担忧较小；但对于私有仓库，传输加密至关重要。

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

漏洞详情

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. Radicle 使用的网络协议未能提供预期的机密性。任何能够观察到两个节点之间网络路径的人都可以读取它们交换的数据，因为数据是以明文形式发送的。Konstantinos Maninakis 于 2026 年 6 月 24 日向我们报告了此问题。您可以访问 https://maninak.com/blog/radicle-cleartext-transport-vulnerability/ 阅读他关于此问题的文章。我们已向上游报告，详见此 Issue。

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. 连接握手过程中的对等身份验证存在缺陷，允许冒充。攻击者可以连接到您的节点并提供一个非其自身的节点 ID（Node ID）。私有仓库仅与列入白名单的节点 ID 共享。伪造白名单节点 ID 的攻击者可以直接获取私有仓库，而无需处于网络路径上。cryptocode 于 2026 年 8 月 12 日向我们报告了此问题。我们已向上游提交了修复方案，详见此 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. 第二个漏洞单独利用起来比听起来要困难。要冒充白名单中的节点 ID，攻击者必须首先知道一个。白名单不是公开的，因此不在网络路径上的攻击者必须进行猜测。在实践中，这两个漏洞结合利用时威胁最大：路径上的攻击者可以看到连接两端的节点 ID，且两者通常都在白名单中。攻击者可以在监视时读取交换的所有内容，然后使用看到的节点 ID 按需获取整个仓库。

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. 在安全更新发布之前，停止使用（通过网络）私有仓库。按照下述说明停止对私有仓库进行种子分发（seeding）。不过，您可能希望将私有仓库保留在存储中，即不要完全删除它们，以便在修复版本发布后可以重新开始分发。

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 exfiltration of the contents of private repositories. 使用额外的加密传输方式（如 Tor、I2P 或其他覆盖网络或 VPN 解决方案）不足以保护您的数据。它们虽然能向网络路径上的攻击者隐藏流量，限制了攻击面，但无法防止对等身份冒充，针对性的复杂攻击仍可能导致私有仓库内容被窃取。

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”: 将每个仓库的种子分发策略更改为“阻止”（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. 注意：我们建议使用 rad block 而不是 rad unseed，以防您的节点种子分发策略被设置为“允许”（allow）。rad unseed 会移除仓库的种子分发策略，使节点回退到默认策略。默认策略是“阻止”，因此在默认配置下 rad unseed 足够了。但如果您将默认策略更改为“允许”，则在执行 rad unseed 后，您的节点仍会继续提供该仓库。rad block 会设置明确的阻止规则，节点会优先检查该规则，因此无论哪种配置都有效。

To stop the node completely: 完全停止节点： rad node stop

Three limits on what this achieves: 此操作有三个局限性：

1. It stops your node from serving the repository.
2. 它会停止您的节点提供该仓库。
3. 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.
4. 它不会删除您的本地副本。副本仍保留在 $(rad path)/storage/<RID without the rad: prefix> 中。仅在您明确了解自己正在删除该仓库及其持有的所有分支时，才删除该目录。如有疑问，请勿从存储中删除。
5. 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.
6. 它无法触及已授权对等节点获取的副本。这些对等节点仍持有数据，且它们的节点同样存在这些缺陷。请要求他们也阻止该仓库。
7. It does not undo past exposure. Data that has already synced over the network should be treated as disclosed.
8. 它无法撤销过去的泄露。已经通过网络同步的数据应被视为已公开。

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. 这两个漏洞均位于节点传输层，而非仓库数据模型中。Git 对象和签名引用仍像以前一样在存储层进行验证。攻击者无法伪造代码或身份。机密性缺陷存在于迄今为止发布的每一个 Radicle 版本中。

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. 我们正在积极寻求解决方案。该方案涉及将 Radicle 的网络协议（目前是使用 Noise 的自定义协议）替换为 iroh，这是一个基于开放标准构建的开源对等网络栈。