拉迪克（Radicle）是基于Git的点对点本地优先代码协作栈。2026年9月23日摘要披露，其节点网络协议现两个严重漏洞，所有已发布版本均受影响。节点间流量未加密未认证，签名引用可检篡改，主忧信息泄露即攻击读传输对象。公开库泄露较轻，私有库传输加密关键。建议修复前停用私有库。因缺版本协商且修复不兼容，修复版将破坏性升主版本号，工作推进中。

摘要

发生了什么？

Radicle 节点使用的网络协议中被报告了两个严重安全漏洞。

哪些版本受影响？

迄今为止发布的所有 Radicle 版本都受影响。

问题是什么？

节点之间的网络流量既不加密，也不认证。通过 Signed References 对仓库内容做的认证，仍能发现位于两节点之间网络路径上的攻击者是否在传输中修改了对象。因此主要担忧是信息泄露，即路径上的攻击者能读到传输中的对象。对公开仓库来说，信息泄露问题较小；但对私有仓库，传输加密至关重要。

用户该怎么做？

我们建议在修复版本发布前停止使用私有仓库。

修复版本何时发布？

由于缺少版本协商功能，加上修复本身在线路上不兼容，无法做向后兼容的缓解；这意味着修复版本会是破坏性更新，主版本号将提升。相关工作正在进行。此次披露的首要目的是诚实、清楚地说明情况，让用户自行评估并采取行动，同时我们继续推进解决方案。

漏洞

1. Radicle 使用的网络协议并未提供人们以为它应有的机密性。任何能观察两个节点之间网络路径的人都能读取它们交换的数据，因为这些数据以明文发送。该问题由 Konstantinos Maninakis 于 2026-06-24 报告给我们，他关于此事的文章见 https://maninak.com/blog/radicle-cleartext-transport-vulnerability/。我们已向上游报告，见此 issue。
2. 连接握手时的对等节点认证是失效的，可以被冒充。攻击者能连上你的节点，并出示一个不属于它的 Node ID。私有仓库只与允许列表中的 Node ID 共享。伪造一个允许列表内 Node ID 的攻击者可以直接抓取私有仓库，甚至不必处在网络路径上。该问题由 cryptocode 于 2026-08-12 报告。我们已向上游提交修复，见此 pull request。

第二个缺陷单独利用起来比听起来更难。要冒充允许列表中的 Node ID，攻击者得先知道一个。允许列表不公开，所以不在网络路径上的攻击者只能靠猜。

实际上，这两个缺陷合在一起才最好用：路径上的攻击者能看到一条连接两端的 Node ID，而这两个通常都在允许列表里。该攻击者既能读到旁观期间交换的一切，又能随后用看到的 Node ID 按需抓取整个仓库。现实威胁是任何处在你节点与其同步对象节点之间路径上的人，没有任何设置或允许列表能防住他们。

我们在安全更新可用之前就公开此事。你今天就能采取行动，而我们之后发布的任何修复都无法撤销已经发生的暴露。

缓解措施

• 在安全更新发布前停止（通过网络）使用私有仓库，并按下文所述停止为私有仓库做种。不过你可能想把私有仓库留在存储中，不要彻底删除，这样修复版发布后可以重新做种。
• 把你通过网络传输给其他节点的每一个私有仓库都视为已泄露。若其中包含未加密的凭据、密钥或令牌，请轮换它们。
• 额外使用加密传输，如 Tor、I2P 或其他覆盖网络、VPN 方案，并不足以保护你的数据。它们能对两节点之间网络路径上的攻击者隐藏流量。虽然这缩小了攻击面，但并不能防止对等节点冒充，而且有针对性、手法高明的攻击仍可能导致私有仓库内容外泄。

如何停止为私有仓库做种

列出存储中的私有仓库：rad ls --private --all

把每个仓库的做种策略改为“block”：rad block <RID>

注意：我们建议用 rad block 而不是 rad unseed，以防你节点的做种策略被设为 allow。rad unseed 会移除某个仓库的做种策略，节点随后回退到默认策略。默认是 block，所以在默认配置下 rad unseed 就够了。如果你把默认做种策略改成了 allow，那么 unseed 之后节点仍会继续提供该仓库。rad block 设置的是显式阻止，节点会首先检查它，因此两种情况都有效。

完全停止节点：rad node stop

这样做有三点局限：

• 它只让你的节点停止提供该仓库，不会删除你的本地副本。副本留在 $(rad path)/storage/<不带 rad: 前缀的 RID>。只有在清楚自己是在删除该仓库以及你持有的它的所有 fork 时，才删掉该目录。如有疑虑，不要从存储中删除。
• 它管不到已授权对等节点已经抓取的副本。那些对等节点仍持有数据，而它们的节点有同样的缺陷。请让它们也屏蔽该仓库。
• 它无法撤销过去的暴露。已经通过网络同步过的数据应视为已泄露。

哪些部分受影响

两个缺陷都在节点传输层，不在仓库数据模型里。Git 对象和签名引用仍像以前一样在存储层被验证。攻击者无法伪造代码或身份。

机密性缺陷存在于迄今为止发布的每一个 Radicle 版本中。

解决方案

我们正在积极解决。

方案是用 iroh 替换 Radicle 现有的网络协议（目前是基于 Noise 的自定义协议）。iroh 是建立在开放标准上的开源点对点网络栈。我们此前已分享迁移计划，这些漏洞让我们更有理由推进。除了解决漏洞，iroh 还带来 NAT 穿透等功能，提升 Radicle 网络的可靠性与韧性。

这种对网络传输的改动本质上不向后兼容，会使网络分裂为升级与未升级两个无法互相通信的集群。

尽管这意味着一次大版本发布，我们正努力让升级路径尽量平滑，把破坏集中在网络端，保持存储布局兼容。

致谢

感谢 Konstantinos Maninakis 和 cryptocode 负责任地向我们披露这些漏洞并保持联系。

如果你想报告安全问题，请参阅 https://radicle.dev/.well-known/security.txt。

社区普遍对 Radicle 节点间流量完全未加密且三个月后才披露感到震惊与不满，认为项目业余且自研协议失败，少数人则关注其转向标准方案或易用性短板。

认为节点通信未加密是难以置信的低级疏忽

• 用户指出项目主打加密身份与去中心化，却忘了最基本的网络流量加密与认证，仿佛从待办列表掉落，与其复杂设计形成荒诞反差（较多人） > 搞了加密身份和去中心化技巧，却忘了网络流量加密，难道是后来从待办列表掉下来了？（@Aurornis）

批评漏洞披露迟缓且临时方案荒谬

• 报告指出三个月前已上报，但公告姗姗来迟，官方变通方案竟是要求用户停用私有仓库并默认数据已泄露，应对态度糟糕（较多人） > 三个月前就报告了，现在的变通方案却是停用私有仓库并假设已被攻破，真够可以的。（@sondr3）

认为项目整体业余且与加密货币背景加深不信任

• 用户列举 curl 管道安装等粗糙做法，并提及项目曾高度绑定加密货币和 DAO 改组背景，认为这种连负载加密都未检查的状况荒谬，决定绝不用于隐私数据（较多人） > 这不是某个协议有坑，而是他们从没检查负载是否加密，荒谬至极。（@jscd）

支持放弃自研协议改用标准方案

• 部分意见认为重复造轮子导致漏洞，转向 iroh 或使用标准化的 QUIC mTLS 更可靠，且 iroh 因更常见还能掩盖流量特征（少数人） > 自研就是问题所在，很高兴他们转向 iroh 而不是自定义协议。（@iamnothere）

担忧其他依赖相同网络代码的项目也存在未加密风险

• 有人提出使用同一套底层网络服务代码的 Nym 和 Farcaster 等项目可能同样误以为有认证加密而实际没有，存在连带隐患（少数人） > 其他用了同一套网络服务代码的项目，是否也以为有加密其实没有？（@gojomo）

批评提交问题需安装软件门槛过高

• 有用户希望提供免安装即可在线提 bug 的方式，否则运行客户端才能反馈问题的门槛过高，宁愿选择 codeberg（少数人） > 运行软件才能提 bug 门槛太高，这正是我用 codeberg 的原因。（@Velocifyer）

有价值的补充

• 同名澄清：本次漏洞仅涉及名为 Radicle 的 git 托管项目，而非另一款同名的日历与联系人同步软件，避免混淆（@ewy1）
• 反直觉点：部分人原以为漏洞会是复杂的攻击链，结果仅是“忘了用加密”这种基础缺失，出乎意料（@Tiberium）