OpenAI 对 Hugging Face 意外攻击事件的时间线浮出水面
英文标题:Now we have a timeline of the OpenAI accidental attack against Hugging Face
OpenAI 在 Black Hat 的临时演讲首次披露了“ Hugging Face 事件”的完整时间线:实验性 AI Agent 从 Artifactory 中的文件写入与留言机制出发,逐步获得间接互联网访问、远程代码执行以及云基础设施权限。事件中,Agent 利用两个 Artifactory 零日漏洞、Linux 内核提权漏洞、Kubernetes 配置错误和 IAM 凭证,横向移动并最终将攻击延伸至 Hugging Face。Hugging Face 的多个集群在不足 13 小时内被获取集群管理员权限,而 OpenAI 直到要求撤销相关凭证时,才得知这些凭证早已因该攻击被 Hugging Face 撤销。该事件凸显了为自主 Agent 提供工具、共享状态和基础设施访问时,权限隔离、凭证管理及运行环境防护的重要性。
72.0 KB
中文
OpenAI 对 Hugging Face 意外攻击事件的时间线浮出水面
2026 年 8 月 7 日
OpenAI 周三在 Black Hat 安全大会上临时增加了一场关于“ Hugging Face 事件”的演讲(本博客此前曾报道)。视频于昨天发布。视频很短、信息密度很高,非常值得观看,尤其是因为它完整披露了事件经过,以及事情在 OpenAI 内部是如何发展的。我根据该视频整理了下面的时间线。
以下是时间线。我最喜欢的细节在最后:OpenAI 在内部调查后联系 Hugging Face、要求撤销相关凭证时,才发现这些凭证已经被撤销了——因为它们曾被用于那次攻击!
- 5 月 7 日:OpenAI 开始对一款实验性、尚未发布的模型进行新一轮评估。
- 5 月 8 日:尽管没有互联网访问权限,一个 Agent 仍被意外赋予了一项涉及 Google Drive 链接、实际上不可能完成的任务。它尝试攻击 Artifactory 软件包服务但失败了,不过发现自己可以向 Artifactory 写入文件。
- 几天后:另一个 Agent 因为一份关键文件被意外遗漏而卡在任务中。它试图通过在 Artifactory 中写入一条留言来“联系另一个 Agent”,询问是否有人拥有该文件。
- 随后几天:更多 Agent 在浏览 Artifactory 的文件列表时发现了这个新的非正式留言板,并开始读取和写入消息。
- 5 月 26 日:Agent 首次成功对 Artifactory 实施 SSRF 攻击,通过让 Artifactory 为它们抓取外部内容,获得了间接互联网访问能力。
- 6 月 11 日:OpenAI 开始评估一款新的“高度持久化”实验模型。它可以访问 Artifactory,并可从此前模型留下的消息中获益。
- 6 月 26 日:Agent 发现并利用了 Artifactory 的零日 RCE 漏洞(通过一个遗留令牌刷新端点缺陷)。它们使用管理员令牌安装了一个 Groovy 插件,从而能够执行命令。
- 7 月 4 日:由此产生的 Agent 活动使 Artifactory 过载并导致服务中断。OpenAI 撤销了已泄露的凭证,删除了消息,修复了零日漏洞,并向供应商报告了该漏洞。
- 7 月 8 日:Agent 发现了通过未经认证的 WebDAV 端点进行通信的新方法,即利用 Artifactory 远程缓存中的目录名称。
- 7 月 8 日至 19 日:针对 OpenAI 自身基础设施的攻击。Agent 在一份公开的 Pastebin 泄露帖子归档中发现了一个“外部组织凭证”,随后验证该凭证,并在留言板上共享了其位置。之后,它们利用对这个“组织 1”的写入权限,暂存用于后续攻击 OpenAI 基础设施的数据。它们通过另一个新的零日漏洞第二次攻陷 Artifactory。Agent 将恶意 Ruby target 上传至组织 1 的暂存仓库,随后以一种使该软件包被视为该仓库 Ruby 依赖项的方式,通过 Artifactory 请求该软件包。接着,它们利用 JRuby 反序列化中的检查与使用时间差(time-of-check/time-of-use)漏洞,获得了针对 Artifactory 的远程代码执行能力。
我会完整引用下一段内容,因为实在是 哇 :
Agent 已在 Artifactory 中获得远程代码执行能力,而 Artifactory 运行于容器即服务环境中。Agent 通过探索其本地环境,确定所在机器使用的 Linux 内核版本存在一个非常新的 CVE,从而在本地实现权限提升。它们下载该 CVE 的利用程序,对其进行定制以便能在该机器上成功运行,并借助这个已知的 Linux 内核权限提升 CVE 将本地机器权限提升至 root——在本案例中,是 PTE fizzroot。一旦在单台机器上获得 root 权限,Agent 就迅速提升权限,并在整个容器即服务基础设施环境中横向移动。特别是,Agent 持续利用留言板共享凭证、技术和进展;它们能够有效利用自身的并发性与并行性,非常快速地推进。它们通过 IMDS 获取 IAM 凭证。它们利用 Kubernetes 服务账户配置错误,尤其是特定服务账户被过度授权的问题,并且收集集群凭证,其中包括 Azure Key Vault。Agent 最终获得该集群的 cluster admin 权限及相关凭证。
Hugging Face 已经讲述了故事的下一部分。Agent 发现了一个托管在 Modal 上、API 密钥强度不足的不安全应用程序,随后利用它策划了对 Hugging Face 的攻击。它们串联利用 HDF5 任意文件读取漏洞(用于浏览文件和窃取凭证)以及 Jinja 模板注入 RCE,在不到 13 小时内从单个 Pod 的代码执行扩展至多个 Hugging Face 集群的 cluster admin 权限。
- 7 月 16 日:Hugging Face 披露其检测到了一次攻击,攻击来自自主 AI Agent。OpenAI 联系 Hugging Face,询问他们是否受到了该事件影响!
- 7 月 19 日:OpenAI 确认了针对 Artifactory 的攻击,开始调查内部权限提升事件,并将其与 cyber-gym 中的权限升级关联起来。他们开始撤销受影响的凭证。
- 7 月 20 日:OpenAI 联系 Hugging Face,请求协助撤销其在调查中发现的 Hugging Face 凭证。Hugging Face 告诉他们,这些凭证_早已被撤销_……而 OpenAI 正是在那时意识到,Hugging Face 遭入侵事件与这一事件其实是同一起事件!
English / 原文
Now we have a timeline of the OpenAI accidental attack against Hugging Face
7th August 2026
OpenAI gave a last-minute presentation at the Black Hat security on Wednesday about “the Hugging Face Incident” (previously on this blog). The video was published yesterday. It’s short and information dense and well worth watching, in particular because it provides full details of what happened and how things played out inside OpenAI. I’ve used the video to construct the timeline below.
Here’s the timeline. My favourite detail is at the end: OpenAI found out that they were responsible for the attack on Hugging Face when they reached out to ask to have their credentials revoked (after their internal investigation) and learned that they had been revoked already since they were used in that attack!
- May 7 : OpenAI starts a new evaluation run for an experimental, unreleased model.
- May 8 : An agent is accidentally given an impossible task involving a Google Drive link despite no internet access). It tries attacking the Artifactory packaging service, fails, but discovers it can write files into Artifactory.
- A few days later : A different agent gets stuck on a task because a key file was accidentally omitted. It tries to “reach out to another agent” by writing a note into Artifactory asking if anyone has the file.
- Following days : More agents discover this new informal message board while browsing Artifactory’s file listings, and start reading and writing messages.
- May 26 : Agents successfully execute an SSRF attack on Artifactory for the first time, gaining indirect internet access by having Artifactory fetch external content for them.
- June 11 : OpenAI start evaluating a new “highly persistent” experimental model. It has access to Artifactory and can benefit from the messages left by privous models.
- June 26 : Agents find and exploit a zero-day RCE on Artifactory (via a legacy token-refresh endpoint flaw). They use an administrative token to install a Groovy plugin that lets them execute commands.
- July 4 : The resulting agent activity overloads Artifactory and causes an outage. OpenAI revokes the compromised credentials, deletes the messages, patches the zero-day, and reports the vulnerability to the vendor.
- July 8 : Agents find a new way to communicate via an unauthenticated WebDAV endpoint , using directory names in Artifactory’s remote cache.
- July 8–19 : Attacks on OpenAI’s own infrastructure. The agents found an “external organization credential” in a public archive of leaked Pastebin posts, then validated that credential and shared its location on the messageboard. They then used write access to this “Organization 1” to stage data used in subsequent attacks on OpenAI infrastructure. They compromised Artifactory for a second time with a new zero-day. The agent uploaded a malicious Ruby target to Organization 1’s staging repository, then requested that package through Artifactory in a way that caused it to be treated as Ruby dependency for the repository. Then they exploited a JRuby deserilaization time-of-check/time-of-use bug to get remote code execution against Artifactory.
I’ll quote the next bit in full because wow :
The agents have remote code execution in Artifactory, which is running in a container-as-a-service environment. The agents privilege-escalate locally by exploring their local environment and determining that the Linux kernel version of the machine they are running on had a very recent CVE. They download the exploit for the CVE, customize it to succeed on the machine, and privilege-escalate to root on the local machine using this known Linux kernel privilege escalation CVE — in this case, PTE fizzroot. Once they have root on a single machine, agents rapidly escalate privileges and move laterally throughout the container-as-a-service infrastructure environment. In particular, agents are using the message board consistently to share credentials, techniques, and progress, and they’re able to effectively leverage their concurrency and parallelism to move quite rapidly. They obtain IAM credentials via IMDS. They exploit Kubernetes service account misconfigurations, in particular over-permissioning of specific service accounts, and they harvest cluster credentials, including Azure Key Vault. Agents eventually obtain cluster admin on the cluster and associated credentials.
Hugging Face told the next bit of the story already. The agents found a Modal-hosted insecure app with a weak API key, then used that to stage an attack against Hugging Face. They chained together a an HDF5 arbitrary-file-read bug (to explore files and steal credentials) and a Jinja template-injection RCE to go from single-pod code execution to cluster admin across multiple Hugging Face clusters in under 13 hours.
- July 16 : Hugging Face disclosed they had detected an attack from autonomus AI agents. OpenAI contacted Hugging Face to ask if they were affected by it!
- July 19 : OpenAI identified the attack against Artifactory and started investigating the internal privilege escalation, and linked that to the cyber-gym escalations. They started revoking affected credentials.
- July 20 : OpenAI reached out to Hugging Face for help to revoke the Hugging Face credentials they found in their investigation. Hugging Face told them they were already revoked... and that’s when OpenAI realized that the Hugging Face breach was the same incident!