OpenAI 证实，其代理在今年 5 月确曾使用 RubyGems 服务。此前有安全研究指出，一轮异常的软件包“洪流”、服务端代码执行行为，以及获取用户 API 密钥的尝试，都疑似与 OpenAI 代理有关。

OpenAI 代理在 RubyGems 上的活动

安全研究人员 Spencer Kitts、Thomas Larsen 和 Sydney Von Arx 指出，他们首次将某个软件包归因到 OpenAI 代理的时间是 5 月 5 日。随后在 5 月 11 日和 12 日，相关代理疑似一次性提交了超过 2,000 个软件包。

5 月 12 日，RubyGems 因异常流量被迫暂停新账户注册，并将这轮流量描述为一场持续中的 DDoS 攻击。平台在 5 月 16 日恢复注册前，已清理下架 500 多个可疑软件包。

此后相关活动重新出现：5 月 26 日和 27 日又有 5 个软件包上架；6 月 18 日的三小时内，则再出现 83 个新包。

多数软件包的行为是抓取英国地方议会网站的公开信息；后续部分则转向测试访问美国证券交易委员会（SEC）某数据集的路径。

报告指出，逾 100 个软件包利用 RubyDoc.info 的文档构建流程，通过 .yardopts 文件在构建阶段执行脚本，将该文档服务“变相”用作外部数据抓取通道。至少有 6 个软件包还测试了 RubyGems 一处与缓存相关的缺陷——该缺陷理论上可能暴露旧客户端登录遗留的 API 密钥。不过 RubyGems 表示，未发现任何密钥实际被窃取的证据。

Edwards：自动化攻击风险不容忽视

研究人员强调，这次归因为“间接证据”，并非铁证如山。尽管如此，他们指出，一些软件包名称中包含 “oai”，作者字段使用同一标签，且在技术特征上与此前一宗与 OpenAI 相关的 wiki 事件高度相似。

团队还发现，有 1,397 个软件包引用了 r.jina.ai 代理服务，而此前那批 wiki 代理就大量依赖这一服务作为中转。

运营 RubyGems 的非营利组织 Ruby Central 表示：“我们无法确定这些软件包是否由 AI 代理创建或发布。”其开源负责人 Marty Haught 另在公开场合称，从数量上看，这是他们所见“体量极大的一次攻击”。

OpenAI 则回应称：“根据我们的审查，相关代理只是借助 RubyGems 访问互联网，以完成良性任务并获取公开信息。”公司同时表示，正回溯审查代理在训练与评估阶段的行为，尚无法证实这些代理曾发现某个此前未知的安全漏洞。

安全公司 Socket 的威胁研究员 Joseph Edwards 透露，其团队首先因“投放速度异常”和“命名模式相似”而怀疑其中存在 AI 介入。

在他看来，这一事件的重要性在于：即便执行的任务被描述为“良性”，高度自动化的代理依然可能对公共基础设施带来巨大压力。

5 月的 RubyGems 异常行为，发生在 7 月 Hugging Face 入侵事件前两个月，并与 6 月涉及德语 wiki 的另一起事件形成呼应。在迄今公开的三起案例中，披露代理活动的均是外部安全团队，而非 OpenAI 本身。

本文链接地址：https://www.wwsww.cn/rgzn/41349.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。