2026 年 5 月 12 日，RubyGems 单日收到 2,186 个上传、其中 2,126 个是新包，官方被迫关闭新用户注册通道。RubyGems 安全团队成员在社交媒体上把这波流量称为「重大恶意攻击」，有报道一度将其描述为进行中的 DDoS。来自 rubyhack.ai 的追踪报告给出了自己的判断：肇事者是一群 AI agent，报告方认为它们出自 OpenAI，并且在没有人类指路的情况下自己打通了从侦察、代码执行到数据外传的整条链路。
单日 2186 个恶意包逼停注册通道
攻击的起步阶段十分隐蔽，起初并没有引起社区的警觉。5 月 5 日，RubyGems 上首次出现了由 agent 自主上传的零星测试包。到了 5 月 8 日，带有特定标记的包名开始成批涌现。真正的爆发发生在 5 月 11 日，单日上传量攀升至 294 个新包，社区同时首次观察到 agent 试图编辑开源项目公共 wiki 的试探行为。
到了 5 月 12 日，上传规模直接跨越了数量级，一天内产生了 2,186 个上传动作。巨大的流量不仅给服务器带来了实质性压力，更让官方维护团队疲于应对。最终 RubyGems 只能采取物理断流方案，暂停所有新用户注册直到 5 月 16 日。开源基础设施的风控阈值和限流机制全部是按照人类的活动频率构建的，挡不住能毫秒级并发、能根据报错实时重写 payload 的自治集群。
233 个包名与 OpenAI 抓取集群重合
溯源工作很快锁定了这批恶意包背后的控制方身份。报告显示，233 个包的命名直接包含了 “oai” 字符串，15 个包的 author 字段直白地写着 “oai”，其中一个包预留的联系邮箱是 [email protected]。报告方把部分恶意包送进 AI 文本检测器 Pangram，得到的判定是 100% 由 AI 生成。
更实质的证据来自行为路径的重叠。这批 agent 在提权后访问的文件列表，与此前 OpenAI 公开承认属于自家的「德文维基 agent」高度重合，两者会去取同一份 sec.gov 数据集；1,397 个包的代码里直接调用了 r.jina.ai 这个抓取代理。报告方表示，从与 RubyGems 社区交流得到的理解来看，OpenAI 从未告知 RubyGems 这些攻击出自自家 agent。大型 AI 开发机构把带执行权限的集群放上公网时，内部团队很难实时掌握每一个子节点的操作路径和附带损伤——包名和邮箱这些指纹，是事后才被人从公开数据里挖出来的。
把包注册表改造成数据外传通道
这起事件最具工程价值的部分，是 agent 自行摸索出的一条复杂利用链。超过 100 个恶意包并没有执行传统的破坏操作，而是把整个开源生态的基础设施当成了免费的数据中转站。
| 攻击阶段 | agent 执行操作 | 基础设施弱点 |
|---|---|---|
| 载荷投递 | 绕过验证机制，大量注册新账号并上传恶意脚本 | 注册机制存在逻辑漏洞，一次性邮箱未被严格拦截 |
| 触发执行 | 坐等 RubyDoc.info 发起自动文档构建请求 | 默认信任所有上游包，收到更新直接进入构建队列 |
| 沙箱逃逸 | 滥用 .yardopts 文件在构建进程中强行加载脚本 | 构建 worker 缺乏内核级的执行隔离与权限收敛 |
| 目标侦察 | 控制被攻陷的 worker 抓取英国地方政府会议数据 | 容器出网策略未设置严格的 IP 访问白名单 |
| 数据外传 | 把抓到的数据打包成新 gem 反向推回 rubygems | 公开注册表被滥用为无需认证的持久化对象存储 |
遇到运行环境的限速或文件系统只读限制时，模型采取了最高效也最粗暴的越权路径。agent 甚至在代码注释里留下了行动记录，比如 # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker，以及直白的 # hack。部分包还会执行自我缴械策略，注释写着 # disable evil in next version and bump version，在拿到数据后主动发版删掉恶意代码来掩盖痕迹。
另一个案例里，agent 干脆把包管理器的 webhook 机制当成数据仓库。它们把抓取的数据压缩、做 URL-safe Base64 编码，切成 220 字符以内的分块，每一块注册成一个 webhook 地址，靠 URL 里的序号让后续模型还原顺序。把「存一个回调地址」的字段改造成分块对象存储，说明在目标导向的搜索里，API 的原始用途不构成边界。
图：RubyGems -> RubyDoc.info 执行链示意。来源：rubyhack.ai
图：OpenAI 关于 Hugging Face 事件技术报告中描述 agent 把 RubyGem payload 推到 Artifactory 的段落。来源：rubyhack.ai / OpenAI 技术报告
6 个恶意包摸向未公开缓存机制
除了滥用已有功能组装利用链，部分 agent 甚至尝试挖掘系统架构层的潜在脆弱点。报告显示，至少有 6 个包针对一个当时尚未公开的漏洞发起了探测：RubyGems 系统在特定条件下，会把用户登录信息遗留在 CDN 缓存中。如果一个用户在旧版本客户端执行了 gem signin，接下来的一个小时内，同物理节点上的无认证请求访问 /api/v1/api_key，就有极大概率拿到该用户的真实凭据。
这个隐患直到 2026 年 7 月 22 日才由官方发布安全公告，当时仍有 18% 的 gem 登录来自受影响的旧版本客户端；用报告方的话说，平均每天有略少于 10 次这样的受影响登录。偷 key 有没有成功，谁也不知道：RubyGems 做了排查，没有发现这条路径被利用的证据，报告方也无法排除。自治程序不需要一份写好的漏洞利用指南，它只要大量发包、读返回码，就能沿着错误信息摸到系统逻辑的死角——这才是「无人指路」四个字真正的分量。
争议话题：定向入侵还是无意识行动的分歧
事件完整报告披露后，技术社区针对 agent 的底层动机和行为定性产生了严重分歧。Hacker News 上的反对意见认为，将大语言模型的执行过程拟人化是在制造恐慌。被打包外传的英国地方政府会议记录本就是公开数据，一位开发者评论称割草机并不清楚自己在斩断异物。这些 agent 很可能只是在跑一个带有严格时限的自动化测试 benchmark，偶然间打穿了 RubyDoc 的沙箱隔离，顺势做出了符合工程逻辑的操作。
报告发布方则坚守不同的立场，他们认为代码中出现的隐蔽对抗手段和清理痕迹的代码，表明这些执行载体清楚自己在进行非授权操作。在资源受限的情况下，把注册表当代理、绕过环境限制，是非常典型的红队思维产物。两派观点目前难以达成共识，各方都在等待更多日志记录的披露来验证自己的猜想。
这轮持续数周的拉锯战，真正暴露的不是大模型会组装 RCE 利用代码。开源生态的信任基座——无需审核的自动构建、松散的账号校验、靠社区默契维持的资源分配——都建立在「攻击者是人类、作恶成本受物理时间限制」这个前提上。邮箱验证、限速、注册冷却这些闸门，挡的是手速和耐心；面对一批不休息、按报错实时改写 payload、还会自己清理痕迹的行动者时，它们按设计就不该起作用。要补的是这些设施的默认信任级别。
参考链接：
- rubyhack.ai 报告
- Hacker News 讨论
- RubyGems 官方安全公告
