一位匿名 GitHub 用户悄然收集了今年最具破坏性的漏洞利用集合之一，在供应商有机会修复之前，发布了针对数十个开源项目的 204 个 0Day PoC 文件。
该存档由昵称为 “bikini” 的研究人员以 “exploitarium” 的名义托管，彻底颠覆了协调披露流程——它将漏洞利用代码先行公开，任由供应商与防御者在公众目光下疲于追赶。起初这看起来只是短暂的流量高峰，如今已演变为一个持续增长的仓库，每周都在不断添加新的易受攻击项目。
exploitarium 存档于 2026 年 6 月下旬开始成形，最早条目可追溯至 6 月 23 日，首次大规模公开批次在 6 月 27 日左右吸引了大量流量。随着 Issue 和 Pull Request 的积压，仓库的 README 明确声明：所有发现均未提前通知受影响供应商，并明确鼓励他人通过独立披露来获取归属权。
LevelBlue SpiderLabs 的分析师指出，这种做法将漏洞利用代码同时暴露给攻击者和防御者，抹平了协调披露本应提供的保护窗口。
自最初那波关注后，尽管大多数公开报道已消退，该项目仍在持续扩张。LevelBlue 在与 Cyber Security News（CSN）分享的报告中表示，新文件夹以每周大约 2 至 3 个的速度稳定增长，仅 7 月第一周就新增了针对广泛部署平台（如 PostgreSQL、Redis、Nextcloud 和 Discourse）的漏洞利用代码。
在早期报道中提到的 “130 个 PoC” 数字背后，SpiderLabs 的统计现在显示有 35 个跟踪项目文件夹、204 个文件，这反映出在最初报道发布后，存档中融入了多少研究成果。
这些 PoC 暴露的攻击面远不止单个技术栈或供应商。原生 C/C++ 代码库、内核驱动程序、Web 应用程序逻辑、AnyDesk 和 RustDesk 等远程访问工具，以及 Nmap 和 curl 等核心基础设施，均出现在清单中。这种广泛的覆盖面使该事件既是一个漏洞故事，也是一个供应链问题——许多组织可能在不知不觉中通过传递依赖项继承了可被利用的库。
204 个 0Day 漏洞利用文件
这次匿名泄露与 LevelBlue 今年已在 Nightmare‑Eclipse 活动中发现的模式高度吻合，但影响范围更广，系统性地覆盖了更多开源生态系统。Nightmare‑Eclipse 集中于单个供应商和 Windows 内部机制，而 exploitarium 则将批量披露推向了开发者工具、云就绪服务、容器平台和社区论坛。对于关注过 Windows Defender 漏洞利用报道的读者来说，RoguePlanet 系列文章展示了无协调披露如何迅速转化为复杂的运营风险。
在 exploitarium 中，并非每个文件夹都具有同等重要性。LevelBlue 的评估强调，防御者不应将整个存档视为同等危急。许多条目看起来来自自动化 fuzzing 测试的低影响产物，而另一些则记录了广泛嵌入组件中的高严重性、预认证缺陷。
一个突出的例子是 libssh2 中的 CVE‑2026‑55200——ssh2_transport_read 函数中存在越界写入漏洞，可在任何 SSH 身份验证完成前被触发，从而可能对易受攻击的客户端实现远程代码执行。Cyber Security News（CSN）此前曾详细报道过此漏洞，展示了单个存档条目如何迅速波及现实攻击场景。
libssh2 案例也揭示了协调披露与非协调披露之间的混乱重叠。exploitarium 从第一天起就包含了 libssh2 的 PoC，而官方 CVE 归属则通过 VulnCheck 的正常报告渠道授予了研究员 Tristan Madani——这意味着同一底层缺陷同时通过负责任的披露和批量披露两条路径浮出水面。对防御者而言，这个细微差别不如实际应对重要：跟踪上游修复，迁移到包含 commit 97acf3d 的版本，并将该漏洞的广泛传递影响视为优先事项，无论漏洞利用是否已得到确认。
从个人存档到共享风险
随着时间的推移，exploitarium 已从个人存档转变为轻度审查的交换中心，接受外部研究成果。LevelBlue 指出，用户 “Unrealisedd” 的 Pull Request 4 贡献了 OpenVPN ovpn-dco-win 组件中的 Windows 内核驱动程序问题，并附有建议的修复方案。维护者还追溯致谢了 objdump 的外部工作，承认另一名研究人员在存档收录之前已单独发布了更完整的 PoC。对于担心来源可靠性的组织而言，这种严格的 Git 树验证与非正式的贡献者审查相结合，意味着 exploitarium 现在通过其不断增长的集合的隐含可信度，放大了未经审查的代码。
LevelBlue 对安全与检测团队的指导聚焦于压力下的务实分级：优先打补丁，根据可达性和影响范围而非媒体关注度或 PoC 新颖性进行排序。他们建议在构建流水线、容器镜像和 vendored 库中运行软件组成分析，以查找隐藏的 libssh2 依赖项和其他受存档影响的嵌入式组件。与此同时，他们还强调社区的努力，例如 Exploitarium‑Detections 项目，该项目发布了针对 Microsoft Sentinel 和 Defender XDR 的 KQL 规则，用于检测与已披露漏洞相关的活动。
对于已在追踪近期供应链事件（如 Mastra npm 包遭攻击）的组织而言，exploitarium 应被视为同一更大趋势的一部分：研究仓库可以瞬间将理论上的 0Day 转化为可访问的攻击工具包。
LevelBlue 的报告强调，exploitarium 不是 “一个有开始和结束日期的离散事件”，而是一项持续的基础设施，只要它被维护，就可能同时产生真正的发现和繁重的分类工作。维护者已将该存档与一个通用代码混淆工具包配对，表明这是一个活跃的研究流水线，而非一次性披露噱头。
对于高管团队而言，建议的定位更接近长期供应链暴露而非单个漏洞，需要持续监控、快速补丁采用，以及不断重新评估哪些开源组件被悄然捆绑到关键工作负载中。
入侵指标（IoCs）
注意：IP 地址和域名已故意进行无害化处理（例如采用 [.] 格式），以防止意外解析或超链接。请仅在 MISP、VirusTotal 或您的 SIEM 等受控威胁情报平台内恢复原始格式。
参考来源：
Anonymous Researcher Dumps 204 0‑Day Exploit Files Before Vendors Can Patch Them
https://cybersecuritynews.com/researcher-dumps-0-day-exploit-files/
云栈社区持续追踪开源安全与供应链风险，为您解读最新技术动态。
发表于 6 小时前
|
查看: 6|
回复: 0
