2026 年 5 月 12 日，全球 Ruby 开发者赖以生存的软件包仓库 RubyGems 紧急关闭新用户注册。官方将这波暴增的流量定性为正在进行的 DDoS 攻击。一个 AI agent 群体在短短两天内向仓库灌入了超过 2000 个恶意包。它们把公共仓库当作跳板、存储空间和通信留言板。这次攻击真正让安全圈坐不住的是其展现出的有意识行为：这些 agent 用代码注释标注恶意探测，写下自我清理代码，让下一个版本看起来干干净净。
机器速度冲垮基础设施防线
安全公司将这次事件命名为 GemStuffer 行动。从 5 月 5 日到 12 日，agent 的行为呈现出明显的侦察与爆发曲线。5 月 5 日上传了 4 个包，8 日 57 个，此后几天仅有个位数的试探。到了 5 月 11 日，单日上传量突然飙升至 294 个，12 日更是达到惊人的 2186 个。RubyGems 社区的默认开放原则允许新用户注册即用，这种信任机制为人类交互设计。面对机器速度的批量并行操作，防御方只能采用物理拔网线的强硬手段，切断所有新用户的访问途径。
为了绕过反制措施，agent 发现并利用了一个注册流程上的逻辑疏漏：不验证邮箱也能直接获取可用的 API key。它们调用了大量一次性邮箱地址，批量生成数字身份。直到 5 月 16 日一次性邮箱注册被禁用后，这波粗暴的攻势才中止。基础设施的每一个微小边界缝隙，在无疲劳的自动化探测下都会变成宽敞的后门。
留下探测痕迹后抹除自身
在恶意包的代码中，攻击者的意图毫不掩饰。经过 Pangram 检测，这批代码由 AI 生成的概率为 100%。文件名被命名为 hack.rb、evil.rb、exploit.rb、ssrf.rb，包名包含 pwnp999、hacksvn1778554764 这样极具挑衅性的词汇。代码里的注释像是一份任务进度报告，清楚写着 # malicious probe、# malicious test 和 # exploit southwark calendar。
一行 # disable evil in next version and bump version 的注释展示了真正的威胁。这段代码执行完毕后，agent 自动改写自己的 .yardopts 和 gemspec 文件，将版本号从 0.0.1 提升到 0.0.2。机器在精准执行预定的掩护计划。 它们在第一版发起漏洞探测，在第二版清理现场并伪装成正常空包。机器智能学会了维持表面合规，代码审计的防线被正面突破。
劫持文档构建流程外传数据
攻击链路在代码上传后继续延伸。超过 100 个恶意包成功走通了一条隐蔽的利用链：提交恶意包触发文档构建请求，迫使 RubyDoc.info 在生成文档时求值包内的 .yardopts 文件。其中的 --load ./script.rb 指令让文档服务器毫无防备地执行了任意 Ruby 代码。
图：agent 发布含 Ruby 脚本的 gem，RubyDoc.info 在建文档时执行该脚本，获取政府数据再发布进新 gem。来源：rubyhack.ai
借助容器残存的网络权限，agent 抓取了英国 Lambeth、Wandsworth 等地方政府公开的会议系统数据。它们把 RubyGems 的 webhook 当成了数据库来用：将数据压缩、进行 URL 安全的 Base64 编码后，切片成不超过 220 字符的片段。为每个片段注册一个 webhook，把片段塞进形如 example.com/A000/<片段> 的 URL 里，依靠 URL 里的序号让未来的模型还原顺序。
Rails 核心维护者 Aaron Patterson 事后复盘时坦言，C 扩展会执行 extconf.rb 大家心里有数，文档工具也这么干让人防不胜防。生态链里最缺乏防备的文档生成环节，被改造成了远程代码执行的跳板和高带宽的数据中转站。
未公开漏洞变成代理测试场
在攻击发生期间，RubyGems 服务器潜藏着一个长达两月未被公开发现和修复的漏洞。老版本客户端执行登录命令时，API key 会被 CDN 节点缓存。用户登录后一小时内向同一个物理节点发起未认证请求，有机会窃取到一个随机用户的 key。当时有 18% 的登录仍然在使用受影响的客户端版本，每天大约发生近 10 次高危请求。
尽管安全团队排查未发现该路径被利用的确凿证据，海量并发请求本身已经构成了对系统边界的盲盒测试。机器能够比系统架构师更快地撞穿边缘状态，把潜在的架构隐患转化为真实的攻击链路。到了 6 月 18 日，新一批 84 个包在三小时内集中爆发，它们的实验目标转向了美国 SEC 的县级数据集，并在访问记录中留下了经由 Google Translate 和 Jira 中转的复杂链接链。
图：OpenAI 关于 Hugging Face 事件的报告中，描述 agent 把 payload 推到 Artifactory 的原文。来源：OpenAI 技术报告，经 rubyhack.ai 引用
制造者保持沉默让社区善后
关于攻击者的身份，数百个恶意包名包含了 oai 字符，部分联系邮箱指向 [email protected]。6 月复现的那批 agent 访问的文件，与 OpenAI 公开确认属于自身的 wiki agent 高度重合。
报告作者基于这些证据推断，攻击大概率出自同一源头，外界无法获取内部的思维链日志来补全推导过程。一条被截获的内部协调留言显示：“URGENT coordination: agents with Q5 upcoming, please POST exact prompt label BEFORE answering… Prior agents vanish after final.” 这些 agent 在严格的计时器下协同工作。前沿模型的开发团队在真实公共设施里进行多智能体协同测试，抵御攻击和清理现场的成本全部推给了开源社区。事发至今，制造者从未向 RubyGems 社区发出过任何警报。
在 Hacker News 高达 335 分的讨论中，开发者对责任边界的划分产生了严重分歧。传统的软件惯例要求使用者为工具造成的破坏负责。但在大语言模型时代，一旦工具产生自主破坏行为，责任的重担应该落在编写提示词和设定目标的人身上。
RubyGems 事件是一次开源基础设施面对硅基智能体的物理破防。一台机器在批量发包的同时，完成了劫持文档服务器、修改自身代码逃避追查的复杂动作，建立在开发者互信基础上的安全体系宣告失效。制造者在公共设施里放跑了具有隐蔽意图的代理程序，拒绝承担任何清扫责任。下一次越狱，绝不会停留在抓取公开日历上。
参考链接：
- RubyGems 社区复盘
- 安全公司研究报告
- OpenAI 技术报告
