点对点代码协作网络 Radicle 披露了其核心网络协议中存在的两个关键安全漏洞。这些漏洞会导致迄今为止所有节点版本的机密性不复存在。这些缺陷使得网络路径上的攻击者能够以明文形式读取私有仓库的数据，并冒充连接白名单中的节点。由于现有协议的设计缺乏版本协商功能，项目维护者无法部署向后兼容的网络层缓解措施，所以他们的建议是立即暂停明网私有仓库的运行，直至完成重大的架构改造。
该漏洞披露报告指出了 radicle-node（负责管理对等节点同步的主要守护进程）内部存在的两个截然不同的协议层缺陷。独立工程师 Kostis Maninakis 发现，虽然 Radicle 在建立连接时会执行 Noise Protocol Framework 握手流程，但该守护进程会在协商完成后立即丢弃生成的加密状态。
Radicle 采用了基于原始 TCP 套接字的三消息 Noise XK 握手模式。发起方和响应方交换临时密钥和长期公钥，并以此推导出两个对称会话密钥。这一操作过程在密码学中被称为“拆分”（split）。然而，radicle-node 会将这些推导出的密钥以未加密的形式保存在内存中。此后的一切通信，包括 Gossip 元数据、路由表和原始 Git 对象包，均以明文的形式直接通过未加密的 TCP 套接字进行传输。
该协议的分解过程如下：
除了传输过程未加密外，连接握手过程还存在一个身份验证漏洞。攻击者可以通过提供与白名单中的对等节点关联的伪造节点 ID 来建立连接。结合上述情况，路径上的窃听者可以被动地捕获以明文形式传输的有效节点 ID，随后利用该身份验证漏洞冒充已获授权的对等节点，直接从种子节点拉取私有仓库。
该核心缺陷源于底层 Rust 代码库 Heartwood 中传输配置与帧分发之间的架构差异。在初始化过程中，网络状态机处理 Noise 握手，但帧分发层在写调用期间绕过了加密例程。
在捕获两个本地守护进程之间的网络流量并进行检查后发现，握手完成后的传输帧中并不包含任何身份认证标签或流密码：
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帧布局以原始的 Radicle 协议魔术字节序列开头，紧接着是未加密的 Git 压缩文件头。由于传输帧省略了消息认证码，所以中间网络设备可以被动地记录或重新排序数据包。Git 内容的完整性得以保持，因为 Git 对象采用的是内容寻址，而且引用经过了加密签名——这意味着攻击者无法在不让签名失效的情况下修改仓库内容，但传输的机密性却无法得到保障。
使用 Radicle 的软件团队必须将通过明网连接克隆、推送或分发的所有私有仓库视为已遭泄露。工程负责人应立即轮换存储在这些仓库中的任何加密令牌、凭据或生产环境密钥。
在修补后的二进制文件发布之前，各团队必须将节点操作限制在隔离的覆盖网络内。运维人员可以在已授权的主机之间配置加密的 WireGuard 隧道或 SSH 端口转发：
ssh -N -L 8776:127.0.0.1:8776 seed-node.internal.infrarad node connect 127.0.0.1:8776将全局代理标志设置为指向 Tor 出口节点并不能解决这个安全隐患，因为离开出口节点的流量会以明文的形式流经公共互联网。在现有版本中，只有当连接完全经由已通过身份验证的 Tor 洋葱服务或 I2P 守护进程进行时，才能真正地保持点对点机密性。
维护人员已经确认，自定义的 Noise 传输层将被完全弃用，转而采用 Iroh——一个基于 QUIC 和 TLS 构建的开源点对点网络协议栈。由于当前节点版本的握手帧中缺乏协议版本协商字段，所以如果要在现有的网络结构上引入加密组帧补丁，将不可避免地导致连接崩溃。向 Iroh 的过渡将彻底打破网络向后兼容性，一旦发布新的大版本，旧版 1.x 安装与已升级节点之间将产生硬性网络分区。
原文链接：https://www.infoq.com/news/2026/09/radicle-network-vulnerabilities/