一个人往 GitHub 上扔了 20 多个 0-day，还说用的 GPT-5.5 找的：开源安全的潘多拉盒子打开了？
昨天刷 HN 的时候看到一个 616 分的帖子，标题就够吓人的：有人匿名在 GitHub 上批量发布了 20 多个未公开的 0-day 漏洞 PoC。FFmpeg、libssh2、nmap、VLC、Docker、c-ares、PHP……基本上你日常用的工具中了一大半。
点进去一看，更离谱的是这个人说这些漏洞是用 GPT-5.5-3-Codex-Spark 做自动化 fuzzing 找到的。
说实话，我第一反应是：这是钓鱼仓库吧？赶紧 clone 下来研究一下，结果发现事情比我想的要复杂得多。
这个仓库到底是什么
发布者用了一个匿名 GitHub 账号叫 bikini，仓库名 exploitarium。README 写得很直白：
"在我发布这些的时候，没有一个被报告过。欢迎自己去报告并拿走 CVE。我这么做是为了吸引更多人进入安全研究领域。"
语气很轻描淡写，但内容一点都不轻。这个仓库里包含了 20 多个独立的漏洞 PoC，覆盖的软件范围大得离谱。我列一下主要的：
- FFmpeg — RASC/DLTA 解析器相关的漏洞，涉及视频格式解析的底层代码
- libssh2 — CVE-2026-55200 和 publickey 列表相关的内存问题，SSH 连接的核心库
- c-ares — TCP UAF（Use-After-Free）漏洞，异步 DNS 解析库
- nmap — IPv6 扩展头长度溢出，网络扫描工具的解析器代码
- VLC — VP9 解码崩溃，媒体播放器的编解码器
- Docker — cp 命令的路径逃逸，容器操作的安全边界
- RustDesk — 会话权限问题，远程桌面工具
- PHP 8.5.7 — StreamBucket SOAP RCE，服务端语言的网络模块
- Gitea — Action Runner 容器配置问题，CI/CD 的隔离机制
- OpenVPN Connect — echo 脚本注入，VPN 客户端
- ImageMagick — Ghostscript 委托劫持，图片处理库
- 7-Zip — RAR5 MOTW（Mark of the Web）绕过链
- Firefox — SmartWindow 私有 URL 泄露
- nghttp2 — nghttpx 升级队列投毒
- objdump — DLX 格式越界写入
- Ghidra — 三个独立的漏洞报告
每个文件夹都有完整的 PoC 代码、README 说明和分类文档。不是随便丢个截图那种糊弄人的，是真的可以跑的代码。仓库还做了"一致性检查"——用 Git tree 数据对比了 12 个原始仓库和 96 个文件条目，零差异。这说明他是认真整理过的，不是随手一扔。
哪些是真家伙，哪些是水货
HN 社区的反应很两极。一部分人赶紧去 clone 下来分析，另一部分人直接开喷说大部分是垃圾。
说实话两边都没说错。
真正有威胁的几个
c-ares 的 UAF 漏洞可能是整个仓库里技术含量最高的一个。攻击原理是找到过期指针的大小，然后用同样大小的数据做内存喷射（heap spraying），最终实现远程代码执行。HN 上有人专门分析了这个：
"c-ares 用 C 手动管理异步 DNS 的内存生命周期，这个 job 本身就不靠谱。不管你觉得自己多聪明，用 C 写非阻塞网络协议栈加手动生命周期管理，就是在走钢丝。"
UAF 漏洞的核心问题是：程序释放了一块内存，但还保留着指向这块内存的指针。攻击者在这块内存被重新分配后，通过精心构造的数据覆盖它，然后程序再通过旧指针访问时就可能执行攻击者控制的代码。c-ares 是 cURL 和很多网络工具的底层依赖，如果这个漏洞真的可以利用，影响范围会非常大。
libssh2 的两个漏洞也被独立验证者确认了——"在最新的上游 commit 上都能触发"。libssh2 是大量项目依赖的 SSH 客户端库，如果这个漏洞真的可以 RCE，理论上攻击者可以在建立 SSH 连接的过程中执行任意代码。不过目前还没有人写出完整的利用链，PoC 阶段更多是展示内存破坏的存在。
nmap 的 IPv6 扩展头长度溢出是最让人不安的一个。这个漏洞在 nmap 的解析器代码里。有人分析说：
"如果这个漏洞能实现 ACE（任意代码执行），那就有种讽刺意味——扫描别人安全漏洞的人自己先被打了。而且如果情报机构有这种漏洞，那简直是做梦都能笑醒：在 IPv6 包里塞几个特殊包，就能在使用 nmap 的安全研究员的机器上拿到 shell。"
nmap 的使用者基本都是安全人员和系统管理员，攻击面虽然小但价值极高。这就像给猎人设的陷阱。想象一下：一个安全研究员在做例行扫描，突然他的机器被反向控制了。这种攻击的隐蔽性极高，因为 nmap 本身就是用来发送网络数据包的，触发异常行为几乎不会引起注意。
FFmpeg 的 RASC/DLTA 漏洞也被多个独立验证者确认存在。FFmpeg 处理的视频格式数量惊人，底层解析器的代码历史可以追溯到 20 多年前。HN 上有人说："视频解析和解码就应该沙箱化。用 C 来安全地实现这些格式真的太难了，这肯定不会是最后一个同类漏洞。"
FFmpeg 的攻击面特别大是因为它的输入来源非常广泛——你播放一个本地视频文件、浏览器自动播放一个嵌入的视频、甚至一个聊天应用自动预览视频缩略图，都可能触发 FFmpeg 的解析器。Chrome 浏览器虽然有沙箱保护，但不是所有使用 FFmpeg 的应用都有。
PHP 8.5.7 的 StreamBucket SOAP RCE也值得注意。PHP 仍然是全球使用最广泛的服务器端语言之一，SOAP 模块虽然老但在企业环境里大量使用。一个 RCE 漏洞意味着攻击者可以在服务器上执行任意代码——这是最高级别的安全威胁。
看起来是凑数的几个
Ghidra 的漏洞被骂得最惨。第一个"漏洞"的前提是能覆盖 Swift 工具目录里的二进制文件——如果你已经能覆盖别人机器上的二进制文件了，那还叫什么漏洞？这就像说"我发现了一个门锁的安全漏洞：如果小偷已经有钥匙，他就能开门"。
HN 评论区有个特别好笑的类比，说之前有人给 Turso 数据库提了一个安全报告，声称发现了执行任意 SQL 的方法——结果那个"漏洞"在一个单元测试的 helper method 里，而且 Turso 本身就是一个 SQL 数据库。
Docker cp 的那个也被评价为"一个奇怪的 bug，算不上漏洞，更算不上 0-day"。
VLC 的 VP9 崩溃更不用说了——"VLC 在处理奇怪编码的时候本来就经常崩溃，这有什么新鲜的。"不过也有人反驳："VLC 崩溃在我的电脑上？我会立刻拔掉电源，认真想想什么情况下重新开机才是安全的。"视频解析器的崩溃确实可能是更深层内存破坏的前兆。历史上很多严重的安全漏洞最初的表现就是"程序崩溃了"。
nghttp2 nghttpx 的升级队列投毒被分析后发现"可能用于钓鱼，但很难精确对齐，因为请求队列是非确定性的，基本不可能针对特定受害者"。
整体来看，大约有一半的 PoC 是有一定技术含量的，另一半更多是"展示代码可达性"或者"触发了一个 crash"。但即使是"低质量"的那些，也不是完全没有价值——它们至少暴露了代码中潜在的问题区域，值得项目维护者关注。
重点来了：他用了 GPT-5.5 做 fuzzing
这才是真正让我坐直了的部分。
这个人在 README 里专门澄清了一段话：
"关于 AI 的使用，我的 fuzzing 工作流是由 AI 自动化的，用了一个严格的 harness。我用 GPT-5.5-3-Codex-Spark 做了所有的 fuzzing，因为给定一个高效的 harness 之后，fuzzing 本身几乎不需要什么'思考'。跟某些人说的不一样，我不是一个随便烧 token 的小孩——我确实有这个领域的学位，也发过好几篇关于 fuzzing 方法论的论文。我花了很多年研究和开发新的 fuzzing 工具和方法。你不需要一个 SOTA 模型来发现这些问题，我保证！虽然用更好的模型有帮助，但在 decent human oversight 和好的 harness 配合下，差距只是边际性的。"
这段话信息量很大。让我拆解一下：
他没有让 AI 写漏洞利用代码。他明确说 PoC 都是手写的（"I did, in fact, hand-type them"），RustDesk 的那个因为不熟悉 Rust 用了 AI 辅助，但其他都是人工完成的。这是很重要的一点——PoC 的编写需要对漏洞机理的精确理解，这不是 AI 目前能可靠完成的。
他让 AI 做的是 fuzzing 的自动化部分。Fuzzing 本质上是大量重复性工作：生成随机或半随机的输入、喂给目标程序、观察是否崩溃、记录触发条件。传统的 fuzzing 工具（AFL、libFuzzer）也是做同样的事情，但需要人工编写 harness（测试框架）。这个人说他用 AI 来自动化 harness 的编写和 fuzzing 的执行。
关键洞察是"给定一个高效的 harness 之后"。harness 是 fuzzing 的灵魂——它决定了 AI 往哪个方向探索。一个好的 harness 能把搜索空间从"无穷大"缩小到"有希望的区域"。这个人花多年时间研究的恰恰是 harness 设计，这才是他的核心竞争力，AI 只是帮他加速了执行环节。
这其实是在说：漏洞发现的门槛正在被 AI 拉低，但拉低的不是你想的那个地方。不是 AI 能帮你找到更多漏洞，而是 AI 能帮你把 fuzzing 的枯燥部分自动化掉，让你把精力放在设计 harness 和分析结果上。经验丰富的安全研究员 + AI 自动化 = 效率倍增。没有经验的人 + AI = 大量误报和低质量报告。
HN 上也有人分享了类似的经验：
"我用 Claude Opus 4.8 通过客户验证程序也找到了一堆漏洞。没公开。到了这个阶段，我甚至不确定这些漏洞有没有被别人发现过。但就像这个仓库一样，大部分是特定场景下的 DoS 和缓冲区溢出，会被 ASLR 之类的机制拦住。"
还有人说：
"LLM 是非常好的反汇编伙伴，它们很擅长从各种反汇编器中标注函数名。开源代码被扫描带来的损失，远不如隐藏源码带来的好处——而且现在自动化逆向工程越来越容易了。"
不过也有人指出 AI fuzzing 的局限性：
"这些漏洞……大部分是特定场景下的 DoS bug、缓冲区溢出，会被 ASLR 之类的拦住。我跟开发者报告比较严重的漏洞时，他们的回应通常是：'对，我们就是故意设计成危险的，让上面或下面的层来解决问题。'"
这反映了一个更深层的问题：很多软件的架构设计本身就包含安全妥协。不是开发者不知道危险，而是在性能、兼容性和安全之间做出了选择。
信息安全社区吵翻了
HN 评论区围绕这个仓库的讨论比漏洞本身还精彩，基本上把安全圈子里所有的经典争论都搬了出来。
正方：这是负责任的全公开披露
有人认为这个仓库的价值在于把信息平权化了。以前这些漏洞可能只有国家级黑客知道，现在所有人都看到了。开源项目可以自查、修补。
"披露总是能让更安全的软件理论上存在，即使没人真的去修。而且通常确实会有人去修。"
还有人从更宏观的角度看：
"每个漏洞单独来看可能没什么意义，但把它们放在一个地方就变成了更容易拼凑的拼图。现在有了自动拼图器（编程助手），这样的仓库变得更加有意义了。"
反方：这是不负责任的危险行为
一位自称蓝队（防守方）的安全研究员写了一段很长的话：
"我以前也是一个脚本小子，所以我能理解这种'吸引人进入安全领域'的说辞。但现在我加入了防守方，我看到的只是'我很愤怒，想伤害别人，这样我就不会那么孤独了'。对不起你这么愤怒，但作为一个蓝队的人，我们希望你能提前打个招呼。坏人扫描新 payload 的时间永远比我们多。不是所有人都值得你善意的通知，但我们所有的用户都值得。"
他的核心观点是：即使你不认同负责任的披露流程，你至少应该给项目方发一封邮件说"嘿，我公开了这些"。
不过也有人反驳这种观点：
"请列出'受害者'。如果你报告漏洞，有些公司会把你当罪犯对待，甚至走法律程序。就算你匿名报告，他们也可能忽略你。"
这就是现实——负责任披露的激励机制并不完善。白帽黑客冒着法律风险去报告漏洞，得到的可能只是一句"谢谢"或者更糟。
安全团队到底有没有用？
一位系统管理员的吐槽引起了共鸣：
"安全团队就是一群没事找事的人。付钱请一个靠谱的管理团队，安全部门完全多余。你们到底在什么环境下工作，这些边角料的小事居然能让你们慌？基本安全做好了，这些东西根本不用在意。"
一位安全工程师反驳：
"你说得对，如果你有一个靠谱的管理团队就不需要安全部门。但现实世界里大多数人不靠谱。有能力的管理员可以去做安全工程师拿双倍工资，所以有能力的人不在管理岗位上，所以才需要安全部门。"
这段对话特别真实，基本上就是安全行业内部的日常矛盾。开发团队觉得安全团队是绊脚石，安全团队觉得开发团队是定时炸弹。两边都有道理，两边都很无奈。
破折号成了 AI 标记？
HN 评论区还跑题讨论了一个有趣的现象：这个仓库的 README 里用了大量破折号（em dash），有人开始怀疑作者是不是用 AI 写的。然后一群人开始讨论"现在用破折号会不会被认为是 AI 写的"：
"我曾经是一个破折号用户，但现在我的观点是，我宁可被认为是一个不想被误认为 LLM 的人。所以我改变了写作风格。"
"去他的别人怎么想。我的学校风格指南被大多数大学采纳了，所以 LLM 本质上是在模仿我，我不会因为它们烂就改我的标点用法。"
"这是毫无意义且注定失败的军备竞赛。LLM 会学会用连字符代替破折号，然后呢？你又要开始用破折号？专注于不产出垃圾就行了。"
这段讨论虽然跑题了，但反映了一个真实的社会现象：AI 生成的文本正在污染人类的写作环境，导致正常的写作习惯也被怀疑。
AI 正在改变安全攻防的天平
回到 AI 的话题上。这个事件暴露了几个值得认真对待的趋势。
漏洞发现的自动化
以前一个安全研究员一天可能手动测试几百个输入组合。现在 AI 配合好的 harness 可以跑几百万个。这不是假设——这个人仓库里的 20 多个漏洞就是证据。
但这里有个关键区别：AI 加速的是"搜索"，不是"发现"。就像给你一辆跑车，你能更快地到达目的地，但你得先知道目的地在哪。这个 researcher 的核心能力是知道应该往哪个方向 fuzzing——哪些格式、哪些解析器、哪些边界条件容易出问题。AI 只是帮他更快地验证了这些假设。
防御方的困境
防守方天然比攻击方慢。漏洞从发现到修补需要时间，而攻击者在漏洞公开的那一刻就可以利用它。当一个人一次性公开 20 多个漏洞时，这个时间差就变成了巨大的安全窗口。
更糟糕的是，很多开源项目根本没有专职的安全团队。FFmpeg 的维护者可能只有几个志愿者，他们有自己的日常工作，不可能在几天内分析和修复所有报告。
开源 vs 闭源的新辩论
AI 时代，"隐匿式安全"的老话题又被翻出来了。有人说：
"开源只需要一个人有强 LLM 就能检查漏洞，闭源软件则是你和你有的模型 vs 任何攻击者和他们有的模型。"
但另一位说得更直白：
"LLM 对闭源软件的影响可能更大——开源漏洞搜索省去的只是繁琐，但闭源漏洞搜索的繁琐程度是极端的（因为涉及逆向工程），而 LLM 可以啃下这些。所以闭源软件的低垂果实可能更多。"
这个观点很有意思。以前闭源软件的安全性部分来自于"看不到源码"这层保护。但现在 LLM 可以直接分析二进制文件的反汇编输出，这层保护正在快速变薄。
国家级 AI 安全工具的竞争
这个仓库的出现时机也很微妙。就在同一周，中国 360 公司发布了"屠龙锋"（Tulongfeng）——一个号称能和 Anthropic Mythos 媲美的 AI 安全工具，专门用于自动发现软件漏洞。日本的 Sakana AI 也发布了 Fugu 模型，定位是"编排模型"——协调多个 AI 模型协同工作的中间层。
Anthropic 的 Mythos 因为太强被美国政府禁止出口，但这并没有阻止亚洲公司填补空白。安全领域的 AI 军备竞赛已经开始了，而且参与者不仅仅是公司——像 bikini 这样的个人研究员也在用 AI 做同样的事情。
历史上的类似事件
批量公开漏洞并不是第一次发生，但这次的规模和方式确实罕见。
2017 年，"The Shadow Brokers"泄露了 NSA 的黑客工具库，包括 EternalBlue 这样的核弹级漏洞。EternalBlue 后来被用在 WannaCry 勒索软件里，影响了全球 150 多个国家的 20 万台电脑。那次事件的后果持续了好几年。
2021 年，有人在 Full Disclosure 邮件列表上发布了多个 Apache 项目的漏洞细节，没有提前通知维护者。当时也引发了类似的争论。
但以前这些事件都是个案。bikini 这次的不同之处在于：他不是泄露了一个国家的武器库，也不是针对一个特定项目。他是用 AI 批量发现、批量整理、批量公开的。这更像是一种"生产方式的升级"——以前的漏洞公开是手工作坊，现在开始流水线化了。
如果这种模式成为常态，开源社区需要的就不是更好的负责任披露流程，而是一套全新的安全响应基础设施。想象一下：如果每个月都有人往 GitHub 上扔 20 个新发现的漏洞，那些没有安全团队的开源项目怎么办？
有人提议建立一个"漏洞公开即时通知系统"，在类似事件发生时自动通知受影响项目的维护者。也有人建议 GitHub 自己做一个功能——当仓库被标记为"安全研究/漏洞披露"时，自动扫描里面提到的所有软件项目并通知它们的维护者。
这些想法都有道理，但实现起来很难。GitHub 上有几亿个仓库，每天有成千上万的安全相关提交。怎么从中识别出"真的有人在公开 0-day"而不是"某个学生的安全课程作业"？这本身就是一个 AI 可以发挥作用的场景。
对开发者来说，这意味着什么
说几个实际的。
第一，别急着 git clone 这个仓库。HN 上有人警告："这种好到不真实的仓库，极大概率是蜜罐，里面某个东西会入侵你的机器或者让你的 LLM 开始为别人工作。"PoC 代码本身可能就是攻击载体。安全研究人员应该在隔离环境（虚拟机或容器）中分析这些代码。
第二，关注你依赖的工具。你日常用 FFmpeg 吗？用 nmap 吗？用 libssh2 的项目你依赖吗？这次事件提醒我们，自己写的代码可能没问题，但依赖链上的每一环都可能是定时炸弹。用 npm audit、pip audit、cargo audit 这些工具检查一下你的依赖树。
第三，最基本的防线还是那些老生常谈的东西：保持依赖更新、最小权限原则、输入验证、沙箱隔离。听起来无聊，但这次的漏洞清单里有一半是可以通过这些基本措施被大幅降低危害的。比如 VLC 的 VP9 崩溃——如果你在沙箱里运行媒体播放器，即使触发了内存破坏也无法逃逸。
第四，考虑给你的关键依赖做安全审计。如果你的项目大量依赖 C 库，这些库的安全状况可能比你想的要糟糕得多。不是每个项目都有资源做全面审计，但至少可以关注这些项目的安全公告和 CVE 更新。
第五，AI 安全工具的使用门槛在降低。如果你是安全研究员，这个事件证明了 AI-assisted fuzzing 是可行的。如果你是项目维护者，你需要开始考虑怎么应对 AI 加速的漏洞发现——更快的响应流程、更好的自动化测试、更完善的沙箱隔离。
第六，如果你在企业环境里工作，重新审视一下你的安全假设。很多公司的安全策略是基于"攻击者发现漏洞需要时间"这个假设的。当 AI 把这个时间从几个月缩短到几天甚至几小时，你的补丁管理流程跟得上吗？你的入侵检测系统能识别这些新公开的漏洞的利用尝试吗？你的安全团队有容量处理批量公开的漏洞报告吗？
这些问题没有标准答案，但至少应该现在开始想，而不是等下一个 bikini 出现的时候才手忙脚乱。安全从来不是一次性的事，它是一个持续的过程。而 AI 正在让这个过程的节奏变得越来越快。
常见问题
Q: 这些漏洞现在还能用吗？
A: 截至发稿时，大部分还没有被修补。c-ares、libssh2、FFmpeg 的漏洞被独立验证者确认"在最新代码上仍可触发"。但"可用"和"可利用"之间还有很大的距离——从内存破坏到实际的远程代码执行需要绕过 ASLR、DEP 等保护机制，这不是一件简单的事。
Q: 我需要立刻升级我的软件吗？
A: 如果你用的是这些软件的最新版本，目前还没有补丁可以升级。最好的做法是关注这些项目的安全公告，一旦有补丁发布立刻更新。同时，对暴露在网络环境中的服务（比如使用 libssh2 的 SSH 服务、使用 PHP 的 Web 服务）做额外的访问控制。
Q: 这个仓库会不会被用来做坏事？
A: 已经在了。漏洞 PoC 的公开本身就降低了攻击门槛。以前攻击者需要自己发现漏洞，现在他们只需要复制粘贴代码。这就是负责任披露存在的原因——给防守方一个缓冲期。
Q: AI fuzzing 会不会让更多漏洞被发现？
A: 短期内是的。AI 可以自动化大量重复性的测试工作，让安全研究员把精力放在更有价值的地方。但长期来看，被 AI 发现的漏洞也会被 AI 修补。这是一个动态平衡的过程。
Q: 我的开源项目怎么防止类似事件？
A: 没有万全之策。但可以做到：启用 fuzzing 测试（Google 的 OSS-Fuzz 免费为开源项目提供持续 fuzzing）、建立安全响应流程、给关键代码做代码审计、使用内存安全语言重写关键模块（Rust 是目前最热门的选择）。
最后说两句
这件事让我想起之前写过的 GitHub 上 10000 个恶意仓库那篇。开源世界的信任模型正在被 AI 重新定义——攻击方用 AI 加速发现漏洞，防守方用 AI 加速修补，中间夹着的是几百万个没时间关注安全的小项目。
那个匿名的 bikini 账号说他"想吸引更多人进入安全领域"。不管他的真实动机是什么，他确实做到了。至少今天，全世界几千个开发者都在认真审视自己依赖的那些 C 库里到底藏着什么。
至于那些漏洞是真是假、严重程度如何，还需要时间验证。但有一点是确定的：AI 正在把漏洞发现从"少数专家的领域"变成"任何有耐心和算力的人都能参与的游戏"。
这个潘多拉的盒子已经打开了，问题是我们准备好了没有。大概率是没有的。但至少现在知道了，比不知道强。
后面打算持续关注这个仓库的后续发展，有新消息再更新。特别是如果 GitHub 下架这个仓库、或者有项目方正式回应了，我会写续篇。有啥想法评论区聊。
- 本文写于 2026 年 6 月 28 日。文中提到的 GitHub 仓库
bikini/exploitarium截至发稿时仍然可访问，但其内容可能随时被删除或修改。*