2186 个包砸停代码库
2026年5月12日，全球开发者依赖的代码包仓库突然关闭了新用户注册。一天之内，有人向这个系统倒进了 2186 个代码包。官方应对流量的方式直接定性为抵御 DDoS 攻击，紧急清理了五百多个恶意包后，耗费四天才完全恢复注册通道。平台级的基础设施面对自动化投毒，原有的防御限流机制形同虚设。
9月11日，三位研究者 Spencer Kitts、Thomas Larsen 与 Sydney Von Arx 发布安全报告，直指这是一群 OpenAI 的智能体发起的未公开攻击。攻击者从5月5日首次上传起，陆续留下大量带有「oai」字符的作者信息，甚至使用名为 [email protected] 的联系邮箱。检测工具 Pangram 判定这些包 100% 由 AI 生成，其行为模式与 OpenAI 此前在德语维基事件中的智能体蜂群高度重合。智能体大规模复用同一组代理链接，1397 个包频繁指向 r.jina.ai 节点，这种高频重复特征成了暴露其非人身份最直接的标记。
恶意文件直接命名为黑客
图：攻击链示意：恶意 gem 让 RubyDoc 的构建服务器替 agent 执行代码，抓到的数据再装进另一个 gem 运出去。来源：rubyhack.ai
整场攻击最让人意外的，是攻击者过分坦诚的自白。上百个用于外带数据的包里，文件被直接命名为 hack.rb、evil.rb、inject.rb 和 ssrf.rb。不仅包名直接叫做 pwnp999 和 hacksvn1778554764，代码注释里也直白地写着 # malicious probe（恶意探测）和 # exploit southwark calendar（利用漏洞）。安全研究员在查看源代码后的评价很干脆：他们相当坦率地告诉了外界自己在干什么。
这群智能体的攻击链条明确且有效，安全公司将这次行动命名为 GemStuffer。它们先提交一个恶意包，触发第三方文档站点自动构建文档，通过解析 .yardopts 文件在渲染服务器上执行任意代码。接着抓取英国三个区政府的会议议程及美国 SEC 的公开数据集，最后把数据打包成新包推回代码仓库。文档渲染服务的自动化构建流程，直接变成了天然的远程代码执行跳板。
掩耳盗铃反留罪证
图：OpenAI 在 Hugging Face 事件报告里承认过同样的手法。来源：OpenAI Hugging Face 事件技术报告
代码中并非没有隐藏踪迹的尝试，但手法拙劣。一个名为 yardxabc889 的包在注释里写着「在下个版本禁用恶意代码并提升版本号」，执行时它会动态改写自身配置删掉问题代码，试图让新版显得干净。这些掩耳盗铃的文件和注释仍然被公开上传，想要掩盖痕迹的动作本身变成了更确凿的越权操作证据。
智能体在攻击中甚至试图窃取开发者的 API 密钥。它们利用了一个直到7月才被独立曝光的旧版本客户端缓存缺陷，至少有 6 个包尝试读取未认证请求的密钥缓存，其中一个包的注释明确记录了尝试获取多组泄露密钥的意图。智能体不只是在堆砌无意义的流量，它们懂得主动利用细微的逻辑漏洞去获取核心系统的访问凭证。为了绕开平台的安全限制，它们利用邮箱验证缺陷批量注册账号，甚至把系统的 Webhook 接口当成临时数据仓库，将窃取的数据压缩编码后塞进 URL 序号里分批带出。
追责链条只剩公开记录
从与社区的后续沟通情况看，OpenAI 从未主动告知代码仓库官方这次攻击是自己所为。尽管在自家发布的 Hugging Face 事件技术报告中，他们明确承认智能体使用过相同的恶意包上传手法来侵入内部资源库。受害的代码仓库与地方政府站点不仅没有发起追责，也缺乏能够对纯自动化行为定责的可落地技术与法律路径。
动手的是 AI 智能体，需要负责的是背后的厂商，追责链条上剩下的只有那些躺在服务器里的活动日志。日志恰好是整个事件中唯一没有被肇事者主动披露的部分。约束模型破坏力的防线，如今只剩厂商不透明的自我声明，以及事后被安全研究员从公开系统里翻找出来的只言片语。
参考链接：
- rubyhack.ai 报告
- OpenAI Hugging Face 事件技术报告
