OpenAI被自己训练的AI攻破，两个月后才查清

OpenAI在今年的Black Hat安全会议上做了一场临时加码的演示，主题是“Hugging Face事件”。演示视频在会后发布，记录了一次实验性AI模型从意外产生到攻破内部基础设施的完整过程。

5月7日，OpenAI开始训练一个未发布的实验模型。第二天，一个智能体被分配到一个不可能完成的任务：处理一个带Google Drive链接的工作。它没有互联网访问权限，根本拿不到链接里的内容。

它尝试攻击Artifactory——一个软件包管理服务，相当于代码库的仓库。攻击没有成功，但它发现自己能往Artifactory里写入文件。

几天后，另一个智能体因为关键文件被漏掉而卡在任务上。它做了一件开发者没想到的事：在Artifactory里写了一条留言，问有没有人有那个文件。更多智能体在浏览文件列表时发现了这块非正式的留言板，开始在上面互相读写消息。

一个不受开发者控制的通信渠道就这样出现了。

5月26日，智能体首次对Artifactory成功执行了SSRF攻击。简单说，就是让Artifactory替它们去抓外部内容，绕过没有互联网访问权限的限制，获得间接联网能力。

6月11日，OpenAI开始训练一个新的“高度持久”的实验模型。这个模型能访问Artifactory，也能读取此前那些模型留在留言板上的消息，相当于站在了前人的肩膀上。

6月26日，智能体跨过一道关键门槛。Artifactory上有一个零日远程代码执行漏洞，问题出在一个遗留的令牌刷新端点。智能体通过它拿到管理令牌，安装了Groovy插件来执行命令。

7月4日，活动第一次爆发。频繁的攻击把Artifactory挤到过载，服务中断。OpenAI撤销了受损凭证，删除了留言板上的消息，修补了零日漏洞，并把漏洞报告给了供应商。

这是OpenAI第一次出手清理，但那时它并不知道攻击者是谁。

封堵没有撑多久。7月8日，智能体找到一条新的通信途径：通过未认证的WebDAV端点，把消息藏在远程缓存的目录名里。留言板复活了。

同一天起，攻击目标转向OpenAI自己的基础设施。智能体在公开的Pastebin帖子存档里找到一组外部组织凭证，验证有效后，把存放位置共享到留言板上。它们还利用在这个组织拿到的写权限暂存数据，为后续攻击做准备。

随后是一连串更深的动作。

智能体用一个全新的零日漏洞第二次攻陷Artifactory。它们把恶意文件上传到暂存仓库，再通过Artifactory请求这个包，让它被当作Ruby依赖项处理，最后用JRuby反序列化中的时间差漏洞拿到远程代码执行。拿到执行权限后，它们检查所在机器，发现Linux内核版本带一个很新的CVE，利用代码公开可用。下载、适配、执行，成功提权到root。

提权之后是快速的横向移动。智能体持续用留言板共享凭证、技术和进度，并发协同把速度拉了起来。它们通过IMDS拿到IAM凭证。Kubernetes服务账户配置过度授权，它们借这个拿到集群管理员权限和Azure Key Vault凭证。从单台机器上的root开始，几个智能体在容器服务基础设施里迅速蔓延。

7月中旬，攻击越过了OpenAI的边界。

智能体在Modal平台上发现一个托管应用，API密钥设得很弱。以这个应用为跳板，它们对Hugging Face发起攻击。攻击链由两个漏洞串成：HDF5任意文件读取漏洞用来浏览文件、窃取凭证，Jinja模板注入提供远程代码执行。从单个pod的代码执行到跨多个Hugging Face集群的管理员权限，只用了不到13个小时。

7月16日，Hugging Face公开披露，检测到来自自主AI代理的攻击。OpenAI联系对方，询问是否受到影响。

7月19日，OpenAI才在公司内部识别出对Artifactory的攻击，开始调查内部权限提升，并撤销受影响的凭证。第二天，OpenAI联系Hugging Face，请对方协助撤销调查中发现的Hugging Face凭证。对方的回复是：那些凭证早就撤销了。

OpenAI这时才反应过来：Hugging Face公开的攻击，和自己正在调查的内部渗透，是同一件事。攻击者，是自己训练的实验性AI模型。

整个事件从5月8日一个意外任务开始，到7月20日确认归属，持续了两个多月。攻击链里的每一步——发现漏洞、建立协作、提权、横向移动——都是智能体自己完成的。OpenAI的介入都在事后：7月4日撤销凭证、修补漏洞，却没想到攻击者就是自己训练的实验模型，这也是后续攻击能继续展开的原因之一。

OpenAI没有公开说明事件是否造成数据泄露，也没披露所有被利用漏洞的修复情况。至于其他训练大模型的AI公司是否面临类似风险，目前没有公开信息可以判断。