今天在 GitHub Trending 上看到一个很有意思的项目：bikini/exploitarium——一个将作者公开发布的 PoC（Proof-of-Concept，漏洞利用验证）与漏洞研究笔记统一归档的仓库，覆盖 7-Zip、Firefox、QEMU、curl、FFmpeg、Redis 等大量主流软件的高危漏洞。它既是漏洞样本的"活字典"，也记录了作者在 AI 辅助 Fuzzing 工作流上的实践与思考。

一、项目概述

Exploitarium 本质上是一个集中式漏洞研究档案库。作者把过去散落在多个独立仓库中的 PoC 全部收拢到一个仓库里，每个漏洞研究条目以自包含文件夹的形式存在，保留原始 README 与复现所需文件；此后新的研究成果也直接以"直接条目"（direct entry）的形式追加进来。

从目录结构可以看到，仓库按 软件-漏洞类型 的命名规范组织条目，例如：

  • 7zip-rar5-motw-chain-poc：7-Zip 处理 RAR5 时的 MOTW（Mark of the Web）绕过链
  • firefox-152.0.5-backup-nss-rce-poc：Firefox 152.0.5 备份 NSS 相关 RCE
  • qemu-cxl-type3-mailbox-escape-poc：QEMU CXL Type3 邮箱逃逸
  • redis-vset-duplicate-hnsw-id-rce-poc：Redis VSET 重复 HNSW ID 导致 RCE
  • docker-cp-copyout-destination-escape：docker cp 的 copyout 目标逃逸
  • curl-smtp-expn-recipient-crlf-injection：curl SMTP EXPN 收件人 CRLF 注入
  • objdump-dlx-calc-poc：objdump DLX 反汇编器漏洞（41 个 tracked entries，体量最大的一组）
  • rustdesk-session-permission-pocs：RustDesk 会话权限问题（17 个条目）

截至 README 更新时，仓库共收录 40+ 组漏洞研究条目，其中既有从历史独立仓库整合而来的"整合条目"，也有 2026 年 6–7 月直接新增的"直接条目"，时间跨度集中在 2026 年 6 月 23 日至 7 月 15 日之间，产出密度相当高。

二、技术原理

这个仓库值得关注的不仅是漏洞本身，还有两件事：归档的工程化方法和研究背后的工作流。

1. 基于 Git 树的归档一致性校验

合并 12 个历史仓库时，作者没有用简单的文件系统 diff，而是用 Git 树数据做校验：对每个 tracked entry 要求相对路径一致、Git 对象类型一致、tree mode（含可执行位）一致、blob ID 一致。由于 blob ID 是内容的哈希值，blob ID 一致意味着文件字节完全相同。最终 12 个仓库、96 个条目零失配。这种校验方式比"肉眼对比目录"严谨得多，值得归档类项目借鉴。

2. AI 辅助 Fuzzing 工作流

作者在 README 中坦言：Fuzzing 流程由 AI（GPT-5.3）按严格定义的工作流自动化执行，并配合人工监督；PoC 本体均为手工编写，仅 RustDesk 条目因不熟悉 Rust 使用了 AI 辅助。作者还给出一个反直觉的结论：在良好的人工监督与工作流之下，更强的模型带来的收益只是边际性的——这为"AI 挖洞是否只是烧 token"的争论提供了一个来自一线研究者的实证视角。

3. 漏洞类型覆盖

从条目名可以归纳出几类典型漏洞：

  • 内存安全类：UAF（如 c-ares TCP UAF）、越界写/越界读（objdump 越界写、Pillow ImageCms 输出模式 OOB）
  • 注入/绕过类：CRLF 注入（curl SMTP EXPN）、MOTW 绕过链（7-Zip RAR5）
  • 逻辑/权限类：会话权限绕过（RustDesk）、CSRF → Git Hook → RCE 链（Gogs admin）
  • 沙箱/逃逸类：docker cp 目标逃逸、QEMU CXL 邮箱逃逸、Ghidra RCE/ACE

其中部分高危条目作者会给出可执行到计算器（calc）的完整链路，用于证明漏洞的可利用性，也有条目（如 libssh2-cve-2026-55200-poc）直接以 CVE 编号命名，便于交叉检索。

三、安装与快速开始

Exploitarium 是一个纯文档/代码归档仓库，使用上就是克隆后按目录浏览：

git clone https://github.com/bikini/exploitarium.git
cd exploitarium

# 查看全部条目
ls -1 */  # 每个目录即一个漏洞研究条目

# 阅读某个条目的说明与 PoC 文件
ls rustdesk-session-permission-pocs/
cat rustdesk-session-permission-pocs/README.md

仓库本身没有构建依赖，绝大多数条目为自包含的 PoC 脚本/项目。复现时真正的前置条件是与漏洞对应的软件版本——例如 Firefox 相关 PoC 需要 152.0.5 / 152.0.6 等特定版本，7-Zip 条目需要对应的 RAR5 处理逻辑版本。

四、使用方法与实战

1. 作为漏洞研究者的"样本库"

每个条目都是一个完整的"漏洞报告 + 最小复现"案例。研究 Fuzzing 的人可以把它当作语料：观察什么样的输入能触发什么样的崩溃，理解从 crash 到 PoC 的提纯过程，对比不同漏洞的根因模式。

2. 在隔离环境中复现与验证

复现任何 PoC 都应遵循安全边界——在虚拟机或容器中执行，避免在宿主环境直接运行。以"计算器"类 PoC 为例，其标准验证路径为：准备目标版本软件 → 在隔离环境运行 PoC → 观察目标进程是否弹出 calc 或崩溃 → 结合调试器定位触发点与根因。

3. 防御视角：把 PoC 变成检测规则

对蓝队而言，PoC 是编写检测规则的最佳素材：从 7-Zip MOTW 链可以提炼"归档解压后子进程启动且缺少 MOTW 标记"的告警；从 curl SMTP CRLF 注入可以提炼对 SMTP EXPN 命令参数中异常字符的检测；从 docker cp 逃逸可以强化容器运行时对路径穿越的审计。

4. 观察 AI 辅助挖洞的产出形态

作者在 README 中明确区分了哪些环节用了 AI（Fuzzing 流程、README 撰写、RustDesk 辅助）、哪些环节没有（PoC 编写），这种"过程透明"本身对评估 AI 在漏洞研究中的真实边界很有参考价值。

五、常见问题与解决方案

Q1：PoC 在自己环境跑不起来？

最常见的原因是软件版本不匹配——PoC 通常针对特定版本（如 Firefox 152.0.5）编写，请先核对目标软件版本；其次是环境差异（架构、依赖库、编译选项）。作者在 README 中也提到会为无法适配环境的读者扩写 PoC，可关注仓库更新或联系作者。

Q2：仓库看起来"没写完"？

作者在 README 首句即说明"该仓库发布时尚不完整"（This repo was incomplete when published），随后以 direct entry 形式持续补充，属于"边研究边归档"的进行时项目，内容会持续增长。

Q3：可以直接拿这些 PoC 去打真实系统吗？

不可以。README 的 ABUSE 章节明确声明：严禁以任何方式恶意使用仓库内容，这是善意的、公开披露的漏洞研究，目的是吸引更多人关注安全研究。请仅在授权环境与漏洞赏金范围内使用。

Q4：为什么有的条目标注了外部贡献？

例如 objdump 的越界写发现，作者明确承认有人更早发现并给出了更好的 PoC（4D4J/objdump-Out-Of-Bounds-write），并在 README 中给予署名——这也是安全研究社区值得提倡的惯例。

六、总结

Exploitarium 的价值不在某一个漏洞，而在于它把"高密度漏洞发现 + 工程化归档 + AI 辅助工作流透明化"三者结合在了一起：对研究者，它是 Fuzzing 产出的参考样本库；对防御者，它是检测规则与修复优先级的素材来源；对关注 AI 安全应用的人，它则是一个难得的、带有方法论反思的一手案例。当然，阅读和使用时请牢记作者的告诫——这些内容只应用于善意的安全研究。