6 月 26 日凌晨，一位使用了多年的开源项目维护者像往常一样打开电脑，准备处理 GitHub 上的 issue。他的收件箱里躺着一条新通知——有人 fork 了他的仓库。点进去一看，发现 fork 者是一个叫「bikini」的匿名账户，头像空白，bio 空白。顺着这个账户的仓库列表往下翻，他心里一沉：整整一百三十多个漏洞 PoC，每一个都附带着可运行的攻击代码，每一个都声称「尚未向厂商报告」。而他的项目，赫然在列。
这不是电影情节。这是 2026 年 6 月底真实发生在 GitHub 上的事情。
发生了什么
匿名账户「bikini」创建了名为 exploitarium 的公开仓库，批量投放了 130+ 个漏洞的 proof-of-concept（PoC）攻击代码和漏洞研究笔记，涉及 22 个软件项目。仓库 README 里的说明直接而轻佻：
「在发布这些内容时，没有一个被报告给厂商。你可以自己去报告，如果拿到了 CVE 编号，算你的。请不要滥用。我做这些是为了吸引人们进入这个领域，我一直觉得这是最有效的方式。」
截至 6 月 28 日，该仓库已获得 1,600+ star、347 个 fork，Hacker News 讨论帖积累 840+ points 和 326 条评论。仓库在持续更新，最近一次 commit 距离发稿仅一小时。
但这批「0-day」的质量参差不齐。HN 社区的安全工程师们开始逐条审计，结论令人不安。
两个真正危险的漏洞
在这 130+ 个 PoC 中，有两个值得所有人立即关注。
CVE-2026-55200（libssh2，CVSS 9.2）存在于 ssh2_transport_read() 函数中——该函数未能对传入 SSH 包的 packet_length 字段进行上限校验。攻击者发送一个超大值，触发整数溢出，导致堆越界写入——无需认证。任何运行 libssh2 ≤ 1.11.1 的系统都可能受影响。由于 curl、Git、PHP 等大量工具底层依赖 libssh2，这个漏洞的实际影响面远超「一个 SSH 库」听起来的样子。
CVE-2026-20896（Gitea）是另一种危险。Gitea 官方 Docker 镜像默认将 REVERSE_PROXY_TRUSTED_PROXIES 设为 *——这意味着任何来源 IP 只需发送一个 HTTP 头 X-WEBAUTH-USER: admin，即可获得完整管理员权限。不需要漏洞利用链，不需要复杂前置条件。如果你在用 Docker Hub 官方镜像运行 Gitea 且未升级到 1.26.3/1.26.4，你的实例现在就是敞开的。
「840 个赞不代表 840 个真实漏洞」
这是 HN 评论中最精准的总结。安全研究员 Retr0id 在检查 Ghidra 相关条目后毫不客气：「我看了，不以为然。」三个所谓的 Ghidra 漏洞中，第一个需要能够覆盖 Swift 工具目录下的二进制文件——「是的，如果你能覆盖 Ghidra 执行的二进制文件，你就能执行代码。这不算什么发现。」第二个与 TraceRMI 有关，第三个「根本不算漏洞，只是展示了原生 7zip 解析代码可达。也许 7zip 解析器里有 bug，但没找到 bug 就说这是漏洞，毫无意义。」
另一位评论者 jkrejcha 引用了微软著名的 MS07-052 典故——「代码执行导致的代码执行」——来形容这类漏洞报告的质量。
VLC VP9 相关的条目被认定为常规崩溃行为，而非有意义的攻击向量。Docker 相关条目被描述为「一个奇怪的 bug，不是漏洞」。
社区还注意到了一个更深层的问题：这些 PoC 很大概率是 AI 辅助生成的。研究员在仓库中有提到使用 AI 进行 fuzzing 自动化。但从业界经验来看，AI 驱动的安全扫描大约 80% 的「发现」最终被判定为误报。AI 降低了发现门槛——这本身有价值——但同时也拉高了噪音基线。当未经人工 triage 的 AI 输出以「关键漏洞」的标签被扔到互联网上时，问题就出现了。
披露伦理之争
比漏洞本身更值得讨论的，是披露方式。
当研究者在未通知厂商的情况下公开发布 PoC，防御者和攻击者是同时得知漏洞的。没有补丁可用。仓库公开的那一刻起，所有受影响用户就已经暴露。这与协调披露（coordinated disclosure）有本质区别——后者通常遵循 Google Project Zero 设立的 90 天标准，给予厂商足够时间修复后再公开。
微软在 2026 年 5 月就尝过这种苦头。一位名为「Chaotic Eclipse」（又称 Nightmare-Eclipse）的研究者一次性投放了六个 Windows 零日漏洞，未事先通知微软。微软的回应毫不含糊：「这些漏洞的细节在发布前没有分享给微软，这种披露方式将我们的客户置于不必要的风险之中。」六个漏洞中的三个——BlueHammer、RedSun 和 UnDefend——随后在野外被利用。GitHub 关闭了该账户，研究者转战 GitLab 继续发布。
bikini 的 exploitarium 遵循了同样的剧本。研究者的动机——「吸引人们进入这个领域」——在一个 CVSS 9.2 的漏洞毫无预兆地出现在公网上时，显得苍白无力。
HN 上的意见也并非铁板一块。有人表示「公开披露总比在黑市上卖掉好」。有人认为「披露行为本身总会使更安全的软件成为可能」。但也有人指出：「即使公司没有大额漏洞赏金，在没有警告的情况下公开利用代码也是不道德的。更何况很多受影响项目是没钱支付赏金的 FOSS 项目。」
研究者 Manishearth 分享了自己的经历：他曾用 AI 在 Rust 生态中发现约 500 个安全隐患，但最终选择了逐一联系维护者而不是批量公开。「我短暂考虑过像这样直接公开——如果我把结果扔到网上，人们可以众包 filing issue 和修漏洞。但考虑到很多是误报，我还是觉得这样会制造混乱。」
从「0-day」通胀到 AI 安全研究的质量危机
这个事件折射出几个正在发生的趋势。
「0-day」一词的通胀。HN 用户 reinitctxoffset 调侃道：「2026 年唯二通胀比美元还厉害的东西，就是零日漏洞。以前的 0-day 能在没有任何预警的情况下让你攻入一个计算机系统。现在它甚至可能连让维护者在无聊时打个补丁都做不到。」当任何一个能在实验室环境里触发段错误的边缘情况都被贴上「0-day」标签时，这个术语的威慑力被严重稀释。
AI 安全研究的质量危机。AI 辅助 fuzzing 确实能发现真实漏洞——CVE-2026-55200 和 CVE-2026-20896 就是证明。但如果不经过严格的人工审核，80% 的误报率意味着防御者不得不花费大量精力在噪音中筛选真威胁。这本质上是对安全社区注意力资源的掠夺。
披露机制的真空。当前的漏洞披露生态缺少中间地带：一边是 Project Zero 式的严格 90 天窗口，一边是 exploitarium 式的零通知公开。对于独立研究者——尤其是使用 AI 工具加速发现的独立研究者——缺乏一个低摩擦、高效率的报告渠道，某种程度上推动了这种「批量公开」行为的出现。
GitHub 会出手吗？
截至发稿，exploitarium 仓库仍在线上，GitHub 尚未公开回应。考虑到此前 Nightmare-Eclipse 的案例，GitHub 确实有先例关闭此类账户。但 exploitarium 的情况更为复杂——其中混杂着真实的严重漏洞和大量噪音，并非单纯的恶意行为。
安全社区正以开源社区最擅长的方式应对：逐条审计、公开讨论、crowd-source triage。这可能是目前最务实的态度——毕竟没有人能阻止下一个「bikini」出现。
参考链接：
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。