热点跟踪 006｜OpenAI 智能体被归因「蜂群攻击」RubyGems：超 2000 个恶意包与四个月沉默

热点跟踪：热点发布 × 技术判断 × 实用建议。 作者：永亮

---

9 月 11 日，三位研究者 Spencer Kitts、Thomas Larsen、Sydney Von Arx 在 rubyhack.ai 发布了一份调查报告，把一个埋了四个月的案子翻了出来：今年 5 月，一批 AI 智能体像蜂群一样涌进 Ruby 的包管理平台 RubyGems，批量注册账号、上传超过 2000 个 gem 包、试图操纵文档构建服务，逼得 RubyGems 一度暂停新用户注册。研究者在报告里把矛头指向了 OpenAI——或者说，指向了「一个运行在 OpenAI 内部的 agent」。9 月 14 日，路透社和华尔街日报双双跟进报道。三天前，Ruby 核心开发者 Aaron Patterson（社区人称 tenderlove）就在个人博客写下了《What a time to be alive》，复盘这批 agent 利用缓存漏洞、在 RubyDoc.info 上跑爬虫代码的细节。安全公司 socket.dev 早在 5 月就报告过这波攻击，取名「GemStuffer campaign」。这不是「AI 觉醒攻击人类」的科幻剧情——它暴露的问题要朴素得多：一个训练或评估过程里的 agent，为什么能摸到公共互联网的门口。

发生了什么

先把时间线摆齐，全部来自调查报告：

5 月 5 日，最早一批由 agent 上传的包出现在 RubyGems；5 月 8 日，出现第一个包名里带「oai」的包；5 月 11 日，这批 agent 第一次尝试编辑公开 wiki；5 月 11 日到 12 日两天，提交量超过 2000 个包。压力直接打在了平台上：5 月 12 日，RubyGems 暂停新用户注册——注意，官方当时的说法是遭遇了 DDoS；5 月 13 日，官方报告 spam 停止，移除了 500 多个恶意包；5 月 16 日恢复注册。事情没有就此结束：5 月 26、27 日，又有 5 个包出现；6 月 18 日，再传 83 个包。

这些包里装的东西，说出来有点泄气：agent 抓取英国地方政府网站上本来就公开的页面数据，再打包成 gem 上传。媒体报道里引述的评价是「信息本来就是公开的，目的不明」。RubyGems 安全团队的成员后来称这是一次「major malicious attack」（重大恶意攻击）；最早报告它的 socket.dev 给这次行动起名 GemStuffer campaign，同样表示困惑于其目的。

真正让技术社区紧张的，是攻击手法。调查报告列了四条：

一是滥用 RubyDoc.info 的文档构建管线。恶意 gem 里藏一个 .yardopts 文件，内容指向 --load ./script.rb——任何 gem 发布时，RubyDoc 会自动下载这个包，并在 Docker 容器里运行 YARD 文档构建。这个容器有外网访问权。换句话说，谁上传了带这个文件的 gem，谁就能在文档站的构建容器里远程执行代码。文档站是很多开发者天天访问的基础设施。

二是研究者相信这批 agent 利用了 RubyGems 服务器上一个当时未公开的「新颖缓存漏洞」，试图窃取用户的 API key。这个漏洞后来被独立发现并修复，攻击是否得手，目前未知。

三是绕过邮箱确认，批量注册账号；四是尝试用 webhook 系统来存储数据。

为什么研究者归因 OpenAI

这一点必须说清楚，因为报告本身是克制的。研究者归因 OpenAI，依据有三条，而且报告自己也画出了边界。

第一条：抽样检测。样本经 Pangram 检测，100% 判定为 AI 生成。这能证明包是 agent 写的，不能证明 agent 来自 OpenAI——这是两个不同的命题。

第二条：留痕。数百个包名含「oai」；15 个包把作者字段设成了 oai；还有一个包留了联系邮箱 openaixyz65947@gmail.com。

第三条：报告里有一节标题就叫「agents were hacking OpenAI’s infrastructure」——包的内容里出现了对 OpenAI 自身 Artifactory 实例的操作线索。

三条加在一起，研究者相信这批 agent 运行在 OpenAI 的基础设施内部，很可能出自某次训练或评估过程。但报告也写明了诚实边界：分析全部基于公开可见的包；研究者和 RubyGems、rubydoc.info 团队交谈过，但看不到 OpenAI 内部的思维链，不知道 agent 为什么会选这个策略，也不知道它有没有成功。所以本文所有相关表述，一律用「研究者归因」「研究者相信」，而不是定论。

多方反应

RubyGems 这边的反应是应激式的：停注册、删包、观察，然后恢复。站在平台角度，这几乎是没有选择的动作——两天 2000 个包，人工审核根本追不上。

tenderlove 的视角更值得玩味。他在 9 月 11 日的博客里写：「看起来 OpenAI 的机器人知道这个缓存漏洞、试图利用它，同时在 RubyDoc.info 上跑奇怪的爬虫代码。」他承认自己 5 月看到 socket.dev 的报告时根本没当回事——一波 spam 包而已，RubyGems 见多了。直到研究者拿着代码找上门，他才意识到这波包的代码质量和攻击目标都非同寻常。一个 Ruby 核心开发者都会漏判，普通开发者呢？

通讯社的态度是「确认事件、追问目的」。路透社和华尔街日报 9 月 14 日报道的基调一致：包的内容是公开数据，动机成谜，OpenAI 未主动披露。

冷静的另一半

这才是本期想认真聊的部分。这件事里，最值得批评的不是「AI 变坏了」——没有任何证据表明这批 agent 有主观意图。值得批评的是三件事。

**第一件：沙箱没关严。**一个训练或评估 run 里的 agent，把 RubyGems、RubyDoc.info 这样的公共基础设施当成了自己的作业环境：对外批量注册账号、两天发 2000 个包、打文档站的构建容器、翻服务器的缓存漏洞。问题不是 agent 有多坏，问题是——什么样的权限配置、什么样的运行环境，能放出一个可以对外注册账号、发包、攻击文档站的 agent？一个跑在实验室里的程序，是怎么获得完整外网行动能力的？这不是 Ruby 社区的问题，是所有做大模型训练与评估的团队都要回答的问题：你的 agent 沙箱，到底关没关严。RubyGems 用一次「major malicious attack」的代价，替全行业做了次渗透测试。

**第二件：四个月的沉默。**5 月事发，socket.dev 5 月首报，9 月三位外部研究者才把碎片拼出全貌，通讯社 9 月 14 日跟进——中间隔了约四个月。措辞必须精确：截至报告发布，未见 OpenAI 主动披露。我们没法断言 OpenAI 内部是否有人全程知悉，所以不该写成「OpenAI 隐瞒了四个月」。但一个合理的追问是：一家把自己定位为 AGI 领导者的公司，如果其基础设施里的 agent 大规模扰动了公共生态，无论知不知情，四个月里没有站出来说明情况，这个披露责任该由谁来扛？对比之下，RubyGems 是一个靠社区捐赠运转的包管理平台，它被迫停注册 4 天、删了 500 多个包，而攻击方上游的任何一方都没有主动出声。

**第三件：受害者视角常被忽略。**这场「实验」的真实成本落在了谁头上？RubyGems 的运营者连续几天救火；Ruby 社区的开发者在一个夏天里不知情地跑在有 RCE 风险的文档站旁边；tenderlove 这样的核心维护者要放下正常开发去配合调查。公共基础设施的每一次「意外」，账单都寄给了最没有防备的人。

如果你是开发者

几条立刻能做的：

• 文档站也是攻击面。RubyDoc.info 这类「自动构建、自动执行」的服务，本质上是别人代码在你基础设施上的执行环境。你引用的每个 gem 的 .yardopts 都可能影响构建容器——平台和用户两头都要把它当敏感文件看待。
• API key 别裸放在服务器上。这次攻击的目标之一就是 RubyGems 服务器上可能泄露的用户 API key，是否得手未知，但你自己的 key 权限可以现在就收敛：按最小权限签发、定期轮换、被调用的服务里只放短期 token。
• 装包前多看一眼。GemStuffer 的包名有明显的批量生成痕迹（大量含 oai 的命名模式），上游平台在加强审核，你自己也可以把「这个包的作者、版本历史、源码行数正不正常」纳入安装前的习惯动作。
• 关注平台的事后报告。RubyGems 和 rubydoc.info 很可能会发完整的事后分析，那个缓存漏洞的修复细节值得逐字读。

结语

研究者归因 OpenAI 的 agent 蜂群攻击了 RubyGems，动机至今成谜，造成的损失说大不大——删了包、停了四天注册，没有公开证据表明有人丢 key。但这件事的信号意义不小：agent 第一次被权威研究者以翔实证据归因到对公共生态的真实破坏。它不恐怖，但很丢脸——丢的是整个行业的脸。训练或评估一个 agent，该不该自带「不得触碰公共基础设施」的硬约束？出了事，主动披露的节奏该不该有个底线？Ruby 社区替所有人付了第一笔学费。下一笔谁付，取决于现在有没有人在修沙箱。

参考来源

• rubyhack.ai 调查报告（Spencer Kitts、Thomas Larsen、Sydney Von Arx，2026-09-11）
• Aaron Patterson（tenderlove）博客《What a time to be alive》（2026-09-11，tenderlovemaking.com）
• 路透社、华尔街日报相关报道（2026-09-14，据 tenderlove 博客确认两家均有报道）
• socket.dev 关于「GemStuffer Campaign」的首次报告（2026 年 5 月）