开源项目的漏洞披露与通报渠道

9 月底到 10 月初，几个开源项目的漏洞用不同的方式公开。Radicle 在修复版推出前公告网络协议的两个漏洞，GitHub Security Lab 在修复之后公开用 AI agent（能自行执行多个步骤的 AI 工具）找到的 Android App 漏洞。Xray-core 2 月那次修复是否告知用户，Exclave 的协作者与 Xray-core 的作者说法不同。Google 的开源软件漏洞奖励计划也从 10 月 1 日起停收产品漏洞通报。

用 Radicle 私有 repo 的人、OsmAnd 与 Wikipedia 的 Android 用户，以及用 Xray-core 的固定功能指定公开 CA 证书的用户，都要确认自己的版本或设置。Radicle 到 10 月 8 日还没有修复版，公告建议修复前停止使用私有 repo。

Radicle 是以 Git 为基础、点对点的代码协作工具，9 月 23 日公告了两个漏洞。节点之间的数据以明文发送，网络路径上的人看得到内容。连接开始时的身份确认也有缺陷，攻击者可以冒充允许清单上的节点取得私有 repo。攻击者要先知道清单上的节点 ID，而清单不公开。

公告写到实际的威胁是两个节点之间网络路径上的人，所有已发布的版本都受影响。repo 的内容有签名，路径上的人篡改内容会被发现，主要的风险是信息外泄。公开的 repo 受的影响较小。

到 10 月 8 日还没有修复版，公告写到修复要把网络层换成开源的 iroh，新旧版本无法互通。公告建议修复前停止使用私有 repo，发送过的私有 repo 都视为已经外泄，里面未加密的证书、密钥与 token 要更换。公告也写明，另外通过 Tor、I2P 或 VPN 连接不足以防止冒充。

GitHub Security Lab 9 月 28 日的文章写到，团队用自己开发的 Taskflow Agent 让 AI 模型逐步检查 Android App 的进入点（其他 App 或链接可以触发的功能）。到发文时，团队通报了 24 个漏洞。作者写到 AI 常回报实际上很难触发的问题，严重度也常估错，每一个发现都要有懂移动 App 的研究者确认。依 GitHub 上 repo 的许可证标注，Taskflow Agent 以 MIT 许可证开源，执行时需要 GitHub Copilot 的授权。

到 10 月 8 日，advisories 页上对得上这篇文章的 Android advisory（漏洞公告）有 5 则，都在 10 月 1 日公开。其中一则让不需要任何权限的恶意 App 取得 OsmAnd 的实时位置，另一则让攻击者通过链接窃取 Wikipedia App 的登录 cookie。依 advisory 的时程，Wikipedia 在 4 月、OsmAnd 在 6 月确认修复，本文查不到修复收在哪一个版本。

Xray-core 是 v2rayN 等代理工具客户端使用的内核组件。7 月 10 日公开的一则 advisory 写到，用 pinnedPeerCertSha256 固定（只接受指定的证书）公开 CA（签发网站证书的机构）的证书时，Hysteria 与 gRPC 两种连接方式的部分路径没有核对服务器名称。同一个 CA 签发的其他证书也会通过验证，连接可能遭到中间人攻击（攻击者在连接中间假冒服务器）。advisory 的严重度标为低，受影响的是 v26.1.13 起的版本，修复版是 v26.7.11。

另一个代理工具 Exclave 的协作者 9 月 29 日在该项目的讨论区写到，他在 2 月 6 日私下报告同一个选项的验证绕过问题。依他的说法，Xray-core 当天以「简化代码」为名修复并发布新版，没有告诉用户。他也写到 7 月 3 日发现修复不完整，于是改用 GitHub 的漏洞通报功能，也就是 7 月那则 advisory。他在 v2rayN 的讨论帖另写到，2 月是通知 Xray-core 的另一位开发者。

到 10 月 8 日，Xray-core 没有在 Exclave 的帖子回应。7 月底到 8 月初，第三方用户在 v2rayN 讨论区提出类似质疑时，Xray-core 的作者写到 2 月修的是另一个问题。作者写到 7 月的漏洞只影响 Hysteria 与 gRPC 固定公开 CA 的情况。作者也写到，2 月的版本说明已经写了「重要修复，请及时升级」，另一位开发者提交 2 月那个修改时没有告诉他其中包含修复。

Google 的开源软件漏洞奖励计划规则页写到，10 月 1 日起不再受理产品漏洞的通报。到 10 月 8 日，供应链相关的漏洞（例如签名密钥外泄）仍然受理，规则页也写到 2027 年第一季会公布后续。依 The Hacker News 的报道，Google 在 X 上的帖子写到原因是自动化提交大增，其中绝大多数无效。报道也写到，帖子没有说这些提交是否由 AI 产生。

导读观点

常见的协调披露流程是披露者私下报告，项目修复之后再发布 advisory，必要时申请 CVE 编号（漏洞的公开识别码）。GitHub 的 repo 可以打开私下报告漏洞的功能，没有打开时，文档建议依 repo 的安全政策或先开 issue 询问联系方式。GitHub Security Lab 的 5 则 advisory 都在修复之后公开，也都有 CVE 编号。Xray-core 的 advisory 在修复的 commit 之后 15 分钟公开，没有 CVE 编号。

Radicle 选择在修复前公开，公告写到用户今天就能采取行动，之后的修复也无法挽回已经发生的外泄。本文推论，提前公开的代价是攻击者也知道了漏洞。

Xray-core 的争议在于修复时要不要明白告诉用户。Xray-core 的作者主张受影响的情况很少，版本说明也已经要大家升级，并写到「只是这种东西需要大张旗鼓通报吗」。Exclave 的协作者写到 Xray-core 发布新版时没有提到漏洞，「用户蒙在鼓里」。两边对 2 月那次修改修了什么的说法不同，本文无法从公开的记录判断。

GitHub Security Lab 的文章写到，AI 辅助的安全研究是目前保护开源项目最好的方式之一。Google 3 月的博客则写到 AI 生成的报告大增，有些包含错误的信息。依 The Hacker News 的报道，Google 10 月停收时的帖子写的原因是自动化提交，没有说明是否由 AI 产生。

在中国大陆，《网络产品安全漏洞管理规定》2021 年 9 月 1 日起施行。规定适用于境内的网络产品提供者、网络运营者，以及从事漏洞发现、收集、发布的组织或个人。网络产品提供者发现或获知漏洞后，要在 2 日内向工信部的网络安全威胁和漏洞信息共享平台报送。向社会发布漏洞信息的组织或个人，不得在提供者提供修补措施之前发布。

认为有必要提前发布的，要与提供者共同评估协商并向工信部、公安部报告，由两部组织评估后发布。规定还要求未公开的漏洞信息不得提供给网络产品提供者以外的境外组织或个人。规定没有定义网络产品提供者是否包含开源项目的维护者，本文也查不到规定对境外项目是否适用。本文对照条文推论，如果适用，Radicle 作为提供者在获知漏洞后需在 2 日内向工信部的平台报送。

依 GitHub 的文档，维护开源项目的人可以在 GitHub 打开私下报告漏洞的功能，或在 repo 放一份写明联系方式的安全政策。

用 Radicle 私有 repo 的人，可以照公告停止分享私有 repo（不会删除本机的副本），发送过的 repo 里未加密的证书要更换。已经同步出去的数据无法收回。用 OsmAnd 或 Wikipedia Android App 的人，本文推论更新到最新版应已包含修复，本文查不到是哪一版。7 月 advisory 描述的漏洞只影响固定公开 CA 证书、走 Hysteria 或 gRPC 的设置，2 月那次修复的范围双方说法不同，本文推论用固定功能的人都可以确认工具内置的 Xray-core 是 v26.7.11 以上。