HackerNews 上有人用了一个很刻薄的比喻：这不是安全研究，这是把上膛的枪放在公共广场上，旁边贴张纸条说”请勿用于犯罪”。
说的就是 Exploitarium。2026 年 6 月 23 日，一个叫 bikini 的匿名 GitHub 账号上线了这个仓库，随后三周里以近乎日更的速度丢出了 35 个漏洞利用 PoC——覆盖 Docker、Firefox、OpenSSH、PHP、Redis、FFmpeg、Ghidra 等几乎所有你能想到的重要开源项目。截至 2026 年 7 月中旬，仓库已收获约 2.3k Stars 和 534 次 Fork。
这些漏洞在发布时没有一个被提前同步给厂商。换句话说，攻击者拿到代码就能发起渗透，而厂商还蒙在鼓里。
这个做法把安全社区劈成了两半。一方认为这是赤裸裸的不负责任，另一方觉得这是历史上最有效的安全意识唤醒方式。真相不在两极——在中间那个所有人都假装看不见的地方。
Exploitarium 的目录结构极其直白。根目录一个 README，一个 cves.md，剩下全是按 项目名-漏洞类型-poc 格式命名的文件夹。作者在 README 里直言不讳：漏洞都没报，CVE 你自己去领，我只是想让更多人进入安全研究这个领域。
但这个说法到底有多少分量，取决于一个更根本的问题：这些 PoC 是脚本小子用 AI 搓出来的垃圾，还是真有研究价值？
不是脚本小子，是科班出身的 AI Fuzzing 专家
在 README 的 Statement 段落里，bikini 花了不少篇幅回应社区质疑。他说自己有相关领域的学位，发表过数篇关于 fuzzing 方法论的论文，AI 只负责自动化 fuzzing 的工作流，而 PoC 本身是手写的。
这点其实很关键。很多批评者预设作者是个”烧 Token 的随机小孩”——一个会用 GPT 但不懂漏洞原理的门外汉。但翻完他的声明和技术细节，你很难维持这个判断。
他用的模型是 GPT-5.3，fuzzing 流程有严格的自动化工作流。他自己的原话是：当配上一个高效的 workflow，几乎不需要什么”思考”。但他也承认，好的 harness 和人工 oversight 远比模型本身重要，更好的模型只有边际提升。这是一个有经验的 fuzzing 研究者对 AI 辅助挖洞的真实评估，不是营销话术。
仓库里有几个 PoC 的质量能侧面印证这个判断。libssh2 的 CVE-2026-55200 是最早被分配 CVE 编号的条目之一，Gitea act_runner 的容器逃逸漏洞 CVSS 评分高达 9.9，Docker cp 的路径逃逸 PoC 文件结构完整且附带详细复现步骤。这些不是随便跑个 AFL 就能撞出来的 crash——每个都展示了清晰的漏洞理解和利用链构造能力。
不过有个细节值得注意。作者提到 RustDesk 的 PoC 借助了 AI 辅助，因为他对 Rust 不够熟悉。这点诚实反而比吹嘘”全栈精通”更让人相信他的专业度。
克隆即用，零门槛
体验这个仓库不需要任何安装步骤——你不需要装它，因为它本来就是给你读的。
git clone https://github.com/bikini/exploitarium.git
cd exploitarium
克隆后你会看到约 35 个自包含的文件夹。每个文件夹里通常有：一个描述漏洞原理的 README、PoC 利用代码（多为 Python 或 C）、有时还有复现环境配置文件。文件夹命名模式统一且信息量大，比如 docker-cp-copyout-destination-escape 一眼就能看出目标软件和漏洞类型。
从阅读价值来看，有几个条目特别值得先看。FFmpeg 的 RASC DLTA 计算 PoC 文件最完整（7 个文件），展示了从 crash 到可利用状态的分析全程。libssh2 的 CVE-2026-55200 是唯一已拿到正式 CVE 编号的条目，PoC 代码简洁且 README 写明了影响版本。Docker 的容器逃逸 PoC 影响面最广，任何在生产环境跑 Docker 的人都应该理解这个攻击面。
但读归读。PoC 代码本身就是攻击程序，在你不确定它做了什么之前，不要在任何非隔离环境中执行。仓库 README 里贴了一段醒目的大写警告——“Do NOT, under any circumstances, use any material in this repository maliciously. Cybercrime is cringe.”——但说实话，GitHub 上能读到这段话的人，和真正会用这些 PoC 搞破坏的人，重合度未必很高。
更值得关注的是作者在 README 中预告的更新节奏。他在 7 月 11 日的提交中写道”Biggest thing yet”（虽然标注了 DELAYED），并承诺之后通常每天一个新 PoC。按照目前的节奏，这个仓库的内容量可能在未来几个月翻倍。
谁该看，谁绝对不该碰
| 场景 | 典型用户 | 价值 | 风险 |
|---|---|---|---|
| 安全研究学习 | 想入行的安全新人 | 理解真实漏洞的利用方式，比教科书直观 | 需要导师指导，避免走偏 |
| 企业安全防御 | 蓝队/安全运营 | 了解攻击面，对照自查资产 | PoC 可直接武器化，内部管理风险高 |
| 渗透测试参考 | 专业渗透测试工程师 | 借鉴利用思路和技巧 | 需确认授权范围，在合法目标上操作 |
| 学术研究 | 漏洞挖掘研究者 | 研究 AI 辅助 fuzzing 的方法论 | 引用的同时也应质疑其负责任披露的缺失 |
不适用的情况同样需要说清楚。如果你只是想找个能”即插即用”的攻击工具——这个仓库不适合你，而且你也不该碰它。如果你是企业的安全小白，想通过翻 PoC 来检查自家系统——别这么干，你没经验的情况下大概率会误判，或者更糟，在真实系统上执行了不应该执行的代码。
如果你是安全研究者，想看看 AI 时代的 fuzzing 工作流长什么样，这个仓库的 Statement 段落本身就是一个很好的案例研究。但请注意：作者的研究方法论和负责任披露流程是两码事。你在借鉴前者的同时，不应该认同后者。
价值和风险聊清楚了，但一个更实际的问题还没回答：这个项目能活多久？
一个维护者，一个 Discord，一场即兴实验
社区健康度的评估在这个项目上需要换个视角。传统的 Stars/Issues/PR/贡献者数框架不太适用——这不是一个协作开发的软件项目，而是一个个人研究归档库。
| 指标 | 数据 | 说明 |
|---|---|---|
| Stars | ~2.3k（截至 2026 年 7 月） | 三周内取得，增速极快但增长源是争议性而非功能性 |
| 核心维护者 | 1 人（bikini） | Bus factor = 1，作者停更则项目完全停滞 |
| 社区形式 | Discord（gg/WytKH65ZR） | 作者在 README 顶部放了 Discord 邀请链接 |
| 外部讨论 | HackerNews / Reddit / 知乎 / 掘金 | 讨论热度极高，但集中在伦理争议而非技术协作 |
| 协议 | MIT | 宽松协议，不限制使用方式（这本身也是争议点） |
一个有趣的侧面是，作者在 README 里写了一段话：“Sharing this repo keeps me motivated to continue dropping my findings for you all.”——社区的关注本身就是他的行为燃料。这形成了一个微妙的反馈循环：越多人讨论，他越有动力继续发布。
在中文安全圈，知乎和 V2EX 上的讨论更多聚焦在”企业该怎么自查”而不是”这个行为对不对”。这种务实的态度反而比英文社区的无休止道德辩论更有行动价值。云了个盘（yunpan.plus）的安全团队甚至出了一篇详细的资产自查指南，列出了受影响软件清单和紧急防护建议——这种”别吵了，先修”的反应，可能是整个事件中最理性的声音。
但外部讨论的质量参差不齐。掘金上有一篇介绍文声称 Exploitarium 有”exploitarium.py –list”和”–cve”参数，但实际仓库中根本不存在这样的统一入口脚本。这种二次传播中的以讹传讹，恰恰说明了安全社区信息验证能力的参差。
行业坐标里的另类
如果说有一个角度是几乎所有讨论都绕开的，那就是这个：Exploitarium 不是一个孤立事件，它是 AI 辅助漏洞挖掘进入规模化阶段后的必然产物。
bikini 用了 GPT-5.3 做自动化 fuzzing。这不是什么黑科技。过去两年，fuzzing 工具的 AI 辅助能力已经进化到”一个研究者 + 一个好模型 + 一个好 harness = 以前一个团队一年的产出”的程度。Exploitarium 只是这条路走到一定节点的自然结果——不是第一个，也不会是最后一个。
放在更大的坐标系里看，Exploitarium 的前辈和后继者都不少。在漏洞公开归档这个领域，同类项目各有各的路线。Exploit-DB 是 Offensive Security 维护的老牌漏洞数据库，收录公开 PoC 超过二十年，但它的每条条目背后都有厂商知晓的前提。Google Project Zero 是负责任披露的黄金标准——90 天窗口期、高质量分析报告、推动行业修复文化。Packet Storm Security 走的也是归档路线，但发布节奏远没有 Exploitarium 激进。bikini 的做法跟这些都不同：他不是在建立数据库，是在用”一天一个 0day”的节奏做一场社会实验。他甚至鼓励别人去替他报 CVE——这在传统安全研究圈里相当于把论文发在 arXiv 上然后让别人去投顶会。
真正值得思考的问题有两个。
第一，当一个人能在三周内挖出 35 个跨产品的漏洞时，漏洞披露的旧规则还适用吗？传统的负责任披露流程假设漏洞发现是稀缺的、个别的、有时间窗口的。但 AI 辅助 fuzzing 打破了稀缺性前提。当一个研究者手里有几十个未修复的漏洞时，逐一走正规流程的边际成本已经高到不现实。
第二，也是更棘手的：公开 PoC 是不是真的能吸引更多人进入安全研究？bikini 的假设是”让人看见漏洞有多好玩，他们就会想学”。但这个逻辑的反面同样成立：让人看见漏洞有多容易利用，他们就会想滥用。在 README 里放一段全大写的警告，对这种分流的实际效果接近于零。
我对 Exploitarium 的核心判断是：它在技术层面是一份高质量的安全研究档案，在伦理层面是一个不负责任的公开实验。你不需要在”支持”和”反对”之间二选一——承认它的研究价值，同时拒绝它的披露方式，这是唯一站得住脚的立场。
资源地址
| 资源 | 地址 |
|---|---|
| GitHub | https://github.com/bikini/exploitarium |
| CVE 跟踪 | https://github.com/bikini/exploitarium/blob/main/cves.md |
| Discord 社区 | https://discord.gg/WytKH65ZR |
行了，判断聊完了，说点实际的。
看完之后，先查自己的资产
如果你在负责一个技术团队的安全，这件事最务实的反应不是加入道德辩论。立刻做三件事：
-
拉一份你的服务器和终端上所有软件的清单，对照受影响项目列表逐项自查 -
在补丁发布前限制受影响服务的外部暴露，尤其是远程桌面和容器相关服务 -
部署 IDS/IPS 规则监控异常代码执行和文件外发行为
如果你是一个想学安全的新手，这个仓库是个好教材，但别一个人看。找个有经验的 mentor 带着你读，或者在 Discord 上参与技术讨论而非情绪发泄。安全研究真正难的不是写出 PoC，而是学会如何负责任地处理你发现的东西。
bikini 可能不认同最后一句话，但这恰恰是他的实验没有给出答案的那个问题。