exploitarium：汇总12个仓库与96条记录的漏洞PoC归档
给安全研究人员集中查阅公开漏洞PoC的Git归档，区别是保留12个仓库的原始文件内容。
GitHub bikini/exploitarium 更新 2026-09-05 分支 main 星标 4.5K 分叉 1.2K
Python C Rust 漏洞研究 Fuzzing Git GPT-5.3 公开PoC

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你正在研究c-ares、curl、Firefox或libssh2等组件的公开漏洞PoC。
    README的“Exploitarium”章节列出了c-ares、curl、Firefox和libssh2等直接条目。
  • 你需要核对旧仓库归档是否保持Git文件内容一致。
    README的“Consolidation Check”章节说明比较了Git tree，并要求路径、对象类型、tree mode和blob ID一致。
  • 你想了解GPT-5.3参与fuzzing工作流的公开研究记录。
    README的“Statement”章节写明作者使用GPT-5.3完成全部fuzzing，并保留人工编写的PoC。

不适合，如果你

  • 你需要可复制的安装、构建或运行命令来执行PoC。
    README提供归档校验说明和条目名称，但材料中没有安装、构建或运行命令。
  • 你需要完整的Issue、Pull Request、Release或原始Git历史。
    README的“Consolidation Check”章节明确说明这些仓库级元数据仍在原始仓库历史中。
  • 你的流程要求明确的开源许可证或稳定版本发布。
    项目元数据显示许可协议未指定、版本发布为0个且最新版本为“No releases”。

前置条件

  • README仅确认内容来自GitHub克隆并包含漏洞PoC与研究说明，未列出运行时版本、依赖或硬件要求 / The README only confirms GitHub-cloned content containing vulnerability PoCs and research notes; it lists no runtime versions, dependencies, or hardware requirements.
  • README的“ABUSE”章节要求不得将仓库材料用于恶意行为 / The README's “ABUSE” section requires that repository materials not be used maliciously.

要注意

  • 归档后的Issue、PR、Release不会出现在本仓库中。
    README的“Consolidation Check”章节明确说明这些元数据保留在原始仓库历史。
  • README声明项目发布时不完整，不能据此假设PoC覆盖完整。
    README的“Statement”章节原文为“This repo was incomplete when published”。
  • RustDesk相关内容使用过AI辅助，README文件本身也被说明为完全由AI生成后审阅。
    README的“Statement”章节明确提到RustDesk和AI生成README。

材料未说明

  • 每个PoC的具体依赖、编译步骤、支持版本和运行环境未说明 / Specific dependencies, build steps, supported versions, and runtime environments for each PoC are unspecified.
  • 各漏洞是否已获得CVE、漏洞当前披露状态和厂商修复状态未说明 / CVE assignment, disclosure status, and vendor remediation status are unspecified.
  • 项目许可证未指定，PoC及原始文件的再分发权限未说明 / The project license is unspecified, and redistribution rights for the PoCs and original files are unclear.
  • README未说明如何在隔离环境中安全运行这些exploit PoC / The README does not explain how to run these exploit PoCs safely in an isolated environment.
  • README未说明每个条目的测试结果、可复现率或受影响版本范围 / Per-entry test results, reproducibility rates, and affected version ranges are unspecified.

💡 深度解析

6
不适合 我维护一个开源项目，想参考 RustDesk 和 objdump 相关 PoC 来验证修复，同时必须确认原作者署名、漏洞归因和再发布许可；这个仓库是否足够作为合并来源？
适合读者： 需要复核漏洞归因、许可证和历史上下文的开源软件维护者，关注 RustDesk、objdump 和原独立仓库的 provenance

不适合直接作为合并或再发布来源，因为它保留了代码内容，却没有提供足够的法律授权和完整历史上下文。

  • 项目数据将许可证标为 Unknown，且没有正式 Release；这使复制、修改、重新发布或商业集成的授权边界不清楚。
  • README 的 Consolidation Check 明确说，原仓库的 stars、issues、pull requests、releases 和独立 Git history 仍留在原仓库历史中；合并后的目录不一定包含完整讨论和时间线。
  • Statement 专门承认 objdump finding 已由其他研究者先行发现，并给出 4D4J/objdump-Out-Of-Bounds-write 链接，说明漏洞归因不能只依据当前目录名称判断。
  • README 还说 RustDesk 使用了 AI assistance，且 PoC 本身与 README 的生成方式不同；这进一步要求维护者单独核对作者、第三方代码和披露义务。
  • 项目核心数据：license = "Unknown"；latest_release 为空；release_count = 0
  • Consolidation Check：原仓库的 stars、issues、pull requests、releases 和独立 Git history 未随合并保留
  • Statement："someone beat me to the punch" 及 `4D4J/objdump-Out-Of-Bounds-write` 链接
  • Statement："I did use AI assistance for RustDesk"
材料未说明：每个目录中代码、依赖和文档的原始版权与许可证；原作者是否授权当前仓库重新发布这些内容；各 PoC 对应的 CVE、披露时间线和第三方贡献者清单
适合 我正在研究 GPT-5.3 如何参与模糊测试流程，并希望比较 Python、Rust 和 C PoC 的人工编写部分；这个项目能否作为 AI 辅助漏洞研究流程的案例？
适合读者： 研究 GPT-5.3 辅助模糊测试流程、同时需要区分 AI 生成文档与人工编写 PoC 的安全研究工程师

适合，README 对 AI 在模糊测试、Rust 辅助和文档整理中的边界描述得比较明确，但它不是可复现的 AI 工具包。

  • README 的 Statement 明确写道，作者使用 GPT-5.3 完成 “ALL the fuzzing”，并采用严格工作流；这使项目具备流程研究价值。
  • 同一章节又说明 “None of the actual PoCs themselves were vibe-coded; I did, in fact, hand-type them”，因此可以把 AI 辅助发现流程与 PoC 编写区分开来。
  • README 特别提到 RustDesk 得到 AI assistance，而 README 文件 “entirely AI”；项目语言分布也包含 Python、Rust、C、JavaScript 和 HTML，适合观察跨语言材料形态。
  • 不过项目没有公开 GPT-5.3 的提示词、工具调用记录、模型输出、人工修改差异或可重复的 fuzzing harness，因此不能据此严格复现实验结论。
  • Statement："I used GPT-5.3 for ALL the fuzzing, as barely any 'thought' is necessary when provided with an efficient workflow."
  • Statement："None of the actual PoCs themselves were vibe-coded; I did, in fact, hand-type them."
  • Statement："I did use AI assistance for RustDesk"；"The README files are very clearly entirely AI"
  • 项目数据：Python、HTML、JavaScript、C、Rust 为主要语言
材料未说明：GPT-5.3 的具体提示词、上下文和工具调用方式；哪些漏洞发现由模型提出、哪些由作者独立完成；AI 结果经过了哪些人工验证，以及是否保留了失败样本
视情况 我负责 Firefox、Postgres、OpenSSH 和 QEMU 的产品安全验证，团队需要在隔离环境中检查补丁是否覆盖这些公开 PoC；我能把这个仓库当作漏洞验证基线吗？
适合读者： 维护 Firefox、Postgres、OpenSSH 和 QEMU 的产品安全工程师，想在隔离环境中验证补丁是否覆盖公开 PoC

视情况，它能提供有价值的验证样本，但不足以单独充当正式漏洞基线或补丁覆盖清单。

  • 仓库直接收录 firefox-152.0.5-backup-nss-rce-poc、firefox-152.0.6-stock-page-native-calc-poc、postgres-ri-owner-switched-cast-poc、openssh-agent-lock-provider-bypass 和 qemu-cxl-type3-mailbox-escape-poc，与这些产品的补丁验证目标相匹配。
  • 归档过程对 12 个旧仓库、96 个 tracked entries 做了 Git tree 和 blob ID 一致性校验，适合确认测试材料的字节内容来自原始归档。
  • 但项目洞察明确指出它不提供统一漏洞扫描、资产识别、补丁管理、风险评分或企业级报告功能；README 也说明旧仓库的 issues、pull requests、releases 和独立历史未必保留。
  • 因此它可以支撑代码级或实验级验证，却不能独立证明受影响版本、修复状态、漏洞归因或企业风险结论。
  • Consolidation Check：列出的 Firefox、Postgres、OpenSSH、QEMU 条目
  • Consolidation Check："12 repos and 96 tracked entries with zero mismatches"
  • 项目洞察 usage_limitations：不提供统一漏洞扫描、补丁管理、风险评分或企业级报告
  • Consolidation Check："Repository-level metadata such as stars, issues, pull requests, releases, and separate Git history remain in the original repository histories."
材料未说明：每个条目对应的受影响版本、修复提交和厂商公告关联；PoC 在补丁前后版本上的预期差异和成功判定；产品安全团队是否获得运行或重新分发这些代码所需的授权
适合 我负责 Nextcloud、NodeBB、Gogs 和 Redis 的防御性测试，只能在隔离的非生产环境验证 RCE、CSRF、令牌和权限边界问题；这个归档适合用来挑选针对性测试样例吗？
适合读者： 负责企业内部防御性测试的应用安全工程师，使用 Nextcloud、NodeBB、Gogs 和 Redis，要求在非生产隔离环境验证 RCE 与权限边界问题

适合用于挑选针对性防御测试样例，前提是把它当作研究资料归档，而不是经过验证的企业安全产品。

  • README 直接列出 nextcloud-federated-share-bearer-token-poc、nodebb-activitypub-attributedto-local-uid-spoof-poc、gogs-admin-csrf-git-hook-rce-poc 和 redis-vset-duplicate-hnsw-id-rce-poc，与所需的令牌、身份、CSRF 和 RCE 场景对应。
  • 项目洞察指出，目录通常是按漏洞或目标软件划分的自包含结构，可单独阅读并复制到隔离实验环境；这比从多个独立仓库分别检索更适合建立专题测试材料。
  • README 的 ABUSE 章节明确要求不要恶意使用，并将项目定位为 good-faith、open-disclosure vulnerability research；这与防御性验证方向一致。
  • 但 README 没有统一的受影响版本、修复状态、复现成功标准或企业报告能力，因此不能仅凭目录存在就判定生产资产受影响。
  • Consolidation Check：Nextcloud、NodeBB、Gogs、Redis 条目
  • 项目洞察 architectural_strengths："目录级自包含结构降低了不同PoC之间的耦合"
  • ABUSE："This is good-faith, open-disclosure vulnerability research"
  • 项目洞察 usage_limitations：不提供统一漏洞扫描、补丁管理、风险评分或企业级报告
材料未说明：这些条目对应的产品版本、配置前提和漏洞修复状态；在企业测试环境中运行每个 PoC 的资源、网络和权限要求；是否存在会修改数据、启动持久化行为或影响宿主机的副作用
视情况 我在课程中同时讲 Python、C、Rust 和 JavaScript，想用 Firefox、Postgres、OpenSSH、nghttp2 和 Nextcloud 的真实案例组织练习；这个仓库适合直接作为学生实验教材吗？
适合读者： 为安全课程和 CTF 训练准备跨语言案例、希望让学习者接触浏览器、数据库和网络协议漏洞的讲师

视情况，适合教师挑选真实案例和源码片段，不适合直接当作统一、可开箱即用的学生实验教材。

  • README 将仓库定位为公开 exploit PoC 与 vulnerability research writeups 的归档，且按漏洞或目标软件组织自包含目录，便于教师选择单个主题。
  • 条目覆盖 Firefox、Postgres、OpenSSH、nghttp2、Nextcloud 和 NodeBB 等软件，项目数据还显示 Python、C、Rust、JavaScript、HTML 多语言分布，能支持跨生态教学。
  • 但用户洞察显示不同目录的构建和执行方式不统一，学习者需要分别理解目标软件、版本、编译方式、运行时状态和输入格式；README 也未提供统一安装命令或课程实验流程。
  • 对教学尤其关键的是，README 明确项目发布时不完整，且 ABUSE 要求不要恶意使用材料；因此教师不能把每个目录默认视为完整、稳定或已独立审计的练习。
  • Exploitarium："Most folders contain one of my former standalone PoC repos, preserved with its original README and tracked files."
  • Consolidation Check：Firefox、Postgres、OpenSSH、nghttp2、Nextcloud、NodeBB 条目
  • 项目数据：Python、HTML、JavaScript、C、Rust
  • ABUSE："Do NOT, under any circumstances, use any material in this repository maliciously."
材料未说明：课程目标环境是否满足各 PoC 的版本和平台要求；每个练习的预期输出、评分标准和失败处理方式；是否有适合初学者的目录及其最低先修知识
视情况 我主要使用 Python、C 和 Rust 做模糊测试，想在隔离虚拟机里复现涉及 libssh2、QEMU、Firefox 和 libarchive 的公开 PoC；这个归档能否作为统一的实验材料库？
适合读者： 使用 Python、C 和 Rust 进行模糊测试与漏洞复现、需要在隔离虚拟机中验证历史 PoC 的安全研究人员

视情况，适合作为源码和研究说明的集中入口，但不能当作具备统一构建流程的复现平台。

  • README 说明它是 “A consolidated archive of my public proof-of-concept and vulnerability research writeups”，并保留多数原独立仓库的 README 和 tracked files，适合按目标软件挑选样例。
  • 归档校验覆盖 12 个仓库、96 个 tracked entries，且要求路径、Git object type、tree mode 和 blob ID 一致；这对确认文件未被合并过程改写很有帮助。
  • 内容确实覆盖 libssh2-cve-2026-55200-poc、qemu-cxl-type3-mailbox-escape-poc、多个 Firefox PoC，以及 libarchive-zip-debuginfod-size-boundary。
  • 但 README 没有声明统一的依赖清单、构建系统、测试入口或跨目录执行命令；项目也明确说发布时 “incomplete”。
  • Exploitarium："A consolidated archive of my public proof-of-concept and vulnerability research writeups."
  • Consolidation Check："The check covered 12 repos and 96 tracked entries with zero mismatches."
  • Consolidation Check：列出的 libssh2、QEMU、Firefox、libarchive 条目
  • Statement："This repo was incomplete when published."
材料未说明：每个 PoC 所需的精确软件版本、操作系统、编译器和第三方依赖；各目录是否有独立构建命令、成功判定和清理步骤；当前目标软件版本上这些 PoC 的复现状态

✨ 核心亮点

  • 12个仓库、96条记录完成零不匹配归档
  • 覆盖Python、HTML、JavaScript、C、Rust
  • README披露GPT-5.3参与全部fuzzing
  • 4,509星与1,241个Fork形成明显关注度

🔧 工程化

  • 集中保存c-ares、curl、Firefox等项目的公开漏洞PoC与研究说明
  • 用Git tree比较路径、对象类型、权限位和blob ID完成归档校验

⚠️ 风险

  • README明确包含公开exploit PoC，并要求不得用于恶意行为
  • 项目声明发布时不完整，且没有提供版本或运行依赖
  • 归档不保留原仓库的Issue、PR、Release和独立Git历史

👥 适合谁？

  • 研究c-ares、libssh2、Firefox等组件漏洞的安全研究人员
  • 希望从GPT-5.3 fuzzing说明和PoC源码学习漏洞研究的开发者