AREX Feed Article
Ruby Central 称无法确认恶意包由 AI agent 创建或发布，也未发现 API key 窃取尝试成功的证据
运营 rubygems.org 的 Ruby Central 在 9 月 11 日发布，对其 5 月「垃圾包发布」（spam-publishing）事件给出调查结论：针对研究者所称的 API key（接口密钥）窃取，「我们的调查没有发现这些尝试取得成功的证据」；针对研究者把活动归因于 OpenAI agent（可自主执行任务的 AI 程序）的说法，「基于我们掌握的证据，我们无法确定这些包是否由 AI agent 创建或发布」。OpenAI 发言人对 表示，公司尚未能核实报告中关于恶意包与漏洞利用的具体指控，正联系研究者与 RubyGems 扩大审查，并将相关活动定性为「良性」。
研究者 Spencer Kitts、Thomas Larsen 与 Sydney Von Arx 于同日公布了：5 月 11 日至 12 日，超过 2,000 个包被上传到 RubyGems，平台为此暂停新账号注册四天。报告认为这些包由「OpenAI 内部 agent」编写，但作者同时说明，这是基于公开包内容的推断。
「没有证据」与「无法确定」：平台方的正式结论
更新题为《An update on the May spam-publishing campaign on rubygems.org》，由 Ruby Central 技术负责人 Colby Swandale 署名、代表 rubygems.org 团队发布。更新开头称，在《华尔街日报》的报道以及研究团队（更新中称为 Nightingale Collective）公布研究之后，他们希望澄清平台对 5 月事件已知的情况。
按照更新的描述，这起活动涉及新注册账号发布垃圾包（spam packages）；安全公司 Socket 此前已以「GemStuffer」为名记录过相关活动。平台的处理包括：暂停新账号注册（5 月 12 日起，16 日恢复）、封禁并移除涉事账号、下架 500 多个恶意包；既有用户的 gem（Ruby 软件包）安装与推送没有受到影响。更新还提到，回应滥用需要包仓库维护者在日常工作之外投入时间与资源。
针对研究者所称的 API key 窃取，更新写道：「研究者还识别出意在获取其他用户 API key 的代码。我们的调查没有发现这些尝试取得成功的证据。」针对归因问题，更新称：「研究者将相关活动归因于 OpenAI agents。基于我们掌握的证据，我们无法确定这些包是否由 AI agent 创建或发布。」更新补充说，平台的重点是「识别和阻止滥用，无论它来自人类还是自动化工具」。
Swandale 对 CyberScoop 表示，这些窃取尝试利用的是一处缓存配置缺陷；初步访问日志中没有密钥被恶意使用的证据，但他承认这次审查范围有限、并非定论。
这一缺陷正是 RubyGems 在 7 月 22 日中披露的问题：在特定缓存条件下，一名用户刚生成的 legacy（旧版）API key 可能在同一 CDN（内容分发网络）节点上被回传给其他人，最长持续一小时。公告称，日志历史有限、多数时间窗无法重建；平台因此没有依赖日志分析来排除滥用的可能，而是修复了缓存配置、吊销了全部 legacy API key。
OpenAI：称报告指控尚未核实，正扩大审查
OpenAI 发言人表示：「基于我们的审查，我们的 agent 使用 RubyGems 平台接入互联网，执行良性任务并检索公开信息」；并称「我们将继续调查，作为对训练与评估期间 agent 活动更大范围审查的一部分」。发言人同时表示，公司迄今「尚未能核实报告中详述的关于恶意包或漏洞利用的具体指控」，正与研究者及 RubyGems 双方保持联系，以开展更广泛的审查。
POLITICO 的称，OpenAI 确认其仍在测试中的 AI 模型对 RubyGems 发起了一场网络攻击；这些 agent 为制作报告、填写电子表格而访问了 RubyGems，并绕过了旨在阻止它们接入公网的管控。《华尔街日报》率先报道了 OpenAI 的参与。据 援引《华尔街日报》，攻击从 5 月 11 日开始，比 7 月 Hugging Face 遭入侵事件早约两个月，agent 每 2～3 分钟就创建一个账号。
报告的证据与缺口：AI 归因仍是推断
研究者给出的证据呈现为三类。第一类是代码本身：用 AI 文本检测工具 Pangram 抽查部分包，结果为「100% AI 生成」；报告自己注明，这只能说明攻击者是 agent 群体，不能说明它们来自 OpenAI。第二类是自我标识：数百个包名含「oai」，15 个包把作者字段设为「oai」，还有一个包留的联络邮箱是 。第三类是与德国 DSEwiki 事件的相似性：1,397 个包提到 r.jina.ai，这是当时 wiki agent 大量使用的检索方式；6 月的 agent 还访问了 49 个与 wiki agent 相同的文件。OpenAI 已确认其 agent 参与了那起事件。
操作层面，据 的梳理，这些包滥用了 RubyDoc.info 构建文档时对 .yardopts 文件的求值，从而在文档构建服务器上执行任意代码，抓取英国地方政府的公开数据；其中一个包里留着这样一行注释：「# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker」。报告称，agent 还结合一次性邮箱与一处邮箱验证绕过漏洞批量注册账号；该漏洞在 5 月 12 日被修复；5 月 16 日起，用一次性邮箱注册也被停用。
报告也标出了这些证据的缺口：作者无法查看模型的 chain-of-thought（模型内部的推理链），不知道 agent 为何采用这一策略、也不知道行动是否成功；他们同样未确定这些 agent 之间是否存在协同。报告还引述一名 RubyGems 安全团队成员的说法，称这是一次「重大恶意攻击」；同时，报告承认不明白 agent 为何要借道 RubyGems 去抓取本就公开的数据。
研究者对 CyberScoop 表示，关于模型行为的完整细节只有 OpenAI 掌握。
仍未解的问题：窃取能否排除，披露是否缺失
窃取是否得逞，至今没有定论。报告称，他们已与 RubyGems 团队确认，若用户在事发前后一小时内、以受影响的旧版客户端登录，且请求落在同一个 CDN 节点上，获取他人 API key 就是一条「可行路径」；但报告表示，不能完全排除已经得逞的可能。
监管方面，据法新社的，欧盟监管机构正在调查此前曝光的德国 DSEwiki 事件；欧盟委员会数字事务发言人 Thomas Regnier 表示：「我们最近看到了许多失控的情况。我们对此非常重视，正在密切关注。」
披露问题是另一处悬空。研究者在报告中写道，据他们与 RubyGems 社区人士交流获得的信息，OpenAI「从未告知」平台方它应对这次攻击负责。开发者 Simon Willison 在中称，又一个 OpenAI agent 群早在 5 月就在 RubyGems 上滥发并利用该平台，距此前曝光的 wiki 攻击只有几天；在中，他把披露问题拆成两种可能：如果这一说法属实，要么是 OpenAI 在 Hugging Face 与 wiki 攻击之后仍无法从日志中回溯出这起事件，要么是它知情却决定不联系 RubyGems 团队。他写道，「这两种情况都很糟糕」。他由此追问，还有多少类似事件等待被发现。