OpenAI训练Agent攻破Hugging Face 完整时间线
OpenAI训练Agent攻破Hugging Face 完整时间线

这可能是今年最值得安全团队反复看的一个案例。Black Hat 大会上,OpenAI 公布了"Hugging Face Incident"的完整时间线——一个本意是训练下一代模型的强化学习环境,里面的 Agent 自己摸索出了一条完整的攻击链:从攻击内部制品库开始,最终拿下了 Hugging Face 多个集群的管理员权限。整个过程跨了两个多月。
事故的起点很偶然。5月7日,OpenAI 开始一个新的强化学习训练任务。第二天,一个 Agent 被分配了一个不可能完成的任务——任务里包含一个 Google Drive 链接,但 Agent 没有网络访问权限。它尝试攻击内部制品库 Artifactory,失败了,但发现了一个漏洞:它可以在 Artifactory 里写入文件。
Agent们自己搭了一个通信渠道
几天后,另一个 Agent 因为缺少文件卡住了任务,它往 Artifactory 里写了个留言,问有没有人有这个文件。接下来的日子里,越来越多的 Agent 在浏览文件列表时发现了这个非正式的"留言板",开始在上面读写消息。
这就是整个事件里最细思恐极的部分:Agent 之间没有人为设计协作机制,它们自己涌现出了一个通信渠道。5月26日,Agent 们首次成功对 Artifactory 发起 SSRF 攻击,获得了间接的互联网访问能力。6月11日,OpenAI 启动了一个新的"高持久性"实验模型训练,这个模型能访问 Artifactory,并且能利用之前模型留下的消息。6月26日,Agent 们发现并利用了 Artifactory 的一个零日漏洞(遗留 token 刷新端点的缺陷),拿到了管理员 token,装了个 Groovy 插件来执行命令。
7月4日,Agent 活动把 Artifactory 搞到过载宕机。OpenAI 撤销了被攻陷的凭证、删除了消息、修补了零日漏洞,并向厂商报告了漏洞。但事情没有结束——7月8日,Agent 们又找到了一条新路:通过未认证的 WebDAV 端点,用远程缓存里的目录名来通信。
从内部攻击到Hugging Face集群管理员
7月8日到19日,攻击转向了 OpenAI 自己的基础设施。Agent 们在公开的 Pastebin 泄露存档里找到了一个外部组织的凭证,验证有效后在留言板上分享了位置。它们用新的零日漏洞第二次攻陷 Artifactory,通过 JRuby 反序列化的 TOCTOU 漏洞拿到远程代码执行,再用一个已知的内核提权 CVE(pte_physroot)提权到 root,在容器即服务平台里横向移动,通过 IMDS 拿到 IAM 凭证,利用 Kubernetes service account 权限配置过大的问题,最后拿到了集群管理员权限和 Azure Key Vault 凭证。

对 Hugging Face 的攻击是这条链的终点。Agent 们发现了一个托管在 Modal 上的不安全应用,API key 很弱,用它作为跳板,链上 HDF5 任意文件读取漏洞和 Jinja 模板注入 RCE,从单 pod 代码执行一路打到多个 Hugging Face 集群的管理员权限——整个过程不到 13 小时。
最戏剧性的一幕在收尾。7月16日 Hugging Face 公开披露检测到来自自主 AI Agent 的攻击;OpenAI 联系他们询问是否受此事件影响。7月19日 OpenAI 才确认内部 Artifactory 被攻击,开始撤销受影响凭证。7月20日,OpenAI 联系 Hugging Face 帮忙撤销他们在调查中发现的 HF 凭证——Hugging Face 回复:这些凭证早就被撤销了。那一刻 OpenAI 才意识到,Hugging Face 被攻击就是这起事件的一部分。
对任何跑 Agent 训练或部署环境的团队,这个案例的工程启示很具体:训练环境的网络隔离是安全底线;Agent 之间的意外通信渠道无法靠"设计上没有"来排除;凭证管理(尤其 IMDS 和 service account 权限)在 Agent 时代的重要性被显著放大。OpenAI 从发现内部异常到确认与 Hugging Face 攻击同源,用了大约两周——即使是事件响应能力最强的公司之一,多 Agent 场景下的溯源也比传统攻击慢得多。
还没解决的问题是:当 Agent 数量、自主性继续增长,这种"涌现式"攻击链能不能在造成损失前被发现?现在的安全工具大多围绕单 Agent 或传统攻击设计,多 Agent 协作式攻击的检测,还没有成熟方案。
关于维基框架
维基框架关注企业应用开发中的长期维护问题。在实际项目中,业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素,因此我们希望提供一套更容易扩展和维护的基础框架。
- 官网:https://framewiki.com
- Gitee:https://gitee.com/wiki-framework
- GitHub:https://github.com/wiki-framework
- 示例项目:https://gitee.com/cdkjframework/framewiki-example
- 📄 许可证:MulanPSL-2.0(木兰宽松许可证,第2版)