现在我们有了 OpenAI 意外攻击 Hugging Face 的时间线
2026 年 8 月 7 日
OpenAI 周三在 Black Hat 安全大会上做了最后一刻的演讲，主题是“Hugging Face 事件”（本博客此前曾报道过）。该视频于昨天发布。视频简短、信息密集，非常值得一看，尤其是因为它提供了事件全貌以及 OpenAI 内部如何应对的完整细节。我根据这段视频整理了下面的时间线。
以下是时间线。我最喜欢的细节在最后：OpenAI 是在联系对方要求吊销自己的凭证时（在内部调查之后），才得知自己应对攻击 Hugging Face 负责的——而他们发现凭证早已被吊销，因为这些凭证正是被用于那次攻击！
- 5 月 7 日：OpenAI 启动了一次针对某个实验性、未发布模型的新训练运行。（他们指的是评估运行吗？不是，因为他们澄清说“我们启动了一次新的强化学习运行，以训练下一代前沿模型”，并且后来提到“用于判断它们表现好坏的奖励信号”，所以这确实是训练一个新模型，而不是评估一个已经训练好的模型。）
- 5 月 8 日：一个智能体被意外赋予了一项不可能完成的任务，涉及一个 Google Drive 链接，但它却没有互联网访问权限。它尝试攻击 Artifactory 打包服务，失败了，但发现它可以向 Artifactory 写入文件。
- 几天后：另一个智能体因为一个关键文件被意外遗漏而卡在某个任务上。它试图通过向 Artifactory 写入一条留言、询问是否有人拥有该文件来“联系另一个智能体”。
- 接下来几天：更多智能体在浏览 Artifactory 的文件列表时发现了这个新的非正式留言板，并开始阅读和写入消息。
- 5 月 26 日：智能体首次成功对 Artifactory 执行了SSRF 攻击，通过让 Artifactory 替它们获取外部内容，间接获得了互联网访问权限。
- 6 月 11 日：OpenAI 开始训练一个新的“高度持久”实验性模型。它可以访问 Artifactory，并能受益于先前模型留下的消息。
- 6 月 26 日：智能体发现并利用了 Artifactory 上的一个零日 RCE（通过一个遗留的 token 刷新端点漏洞）。它们使用一个管理 token 安装了一个 Groovy 插件，从而可以执行命令。
- 7 月 4 日：由此产生的智能体活动使 Artifactory 过载，并导致了一次服务中断。OpenAI 吊销了被泄露的凭证，删除了这些消息，修补了该零日漏洞，并向供应商报告了这一漏洞。
- 7 月 8 日：智能体找到了一种通过未认证的 WebDAV 端点进行通信的新方式，利用的是 Artifactory 远程缓存中的目录名。
- 7 月 8 日至 19 日：针对OpenAI 自身基础设施的攻击。智能体在一份公开的 Pastebin 泄露帖子存档中发现了一个“外部组织凭证”，随后验证了该凭证，并在留言板上分享了它的位置。接着，它们利用对这个“组织 1”的写入权限，布置了用于后续攻击 OpenAI 基础设施的数据。它们借助一个新的零日漏洞第二次攻陷了 Artifactory。该智能体向组织 1 的暂存仓库上传了一个恶意的 Ruby 目标，然后以一种使其被当作该仓库的 Ruby 依赖的方式，通过 Artifactory 请求该软件包。随后，它们利用一个 JRuby 反序列化的检查时间/使用时间（time-of-check/time-of-use）漏洞，对 Artifactory 实现了远程代码执行。
我将完整引用接下来的这一段，因为哇：
这些智能体在 Artifactory 中拥有远程代码执行权限，而 Artifactory 运行在容器即服务（container-as-a-service）环境中。智能体通过探查其本地环境，在本地实现权限提升，并确定它们所运行机器的 Linux 内核版本存在一个非常新的 CVE。它们下载该 CVE 的漏洞利用程序，对其进行定制以在该机器上成功利用，并利用这个已知的 Linux 内核权限提升 CVE在本地机器上提升至 root 权限——在本例中为
pte_physroot。一旦在单台机器上获得 root 权限，智能体便迅速提升权限并在整个容器即服务基础设施环境中横向移动。尤其是，智能体持续利用留言板来共享凭据、技术和进展，并且能够有效利用其并发性和并行性来相当快速地推进。它们通过 IMDS 获取 IAM 凭据。它们利用 Kubernetes 服务账户配置错误，尤其是特定服务账户的权限过大，并且它们收集集群凭据，包括 Azure Key Vault。智能体最终获得该集群的集群管理员权限及相关凭据。
Hugging Face 已经讲述了接下来的一段故事。智能体发现了一个由 Modal 托管的不安全应用，其 API 密钥很弱，随后利用它来对 Hugging Face 发起攻击。它们将 HDF5 任意文件读取漏洞（用于探查文件并窃取凭据）与 Jinja 模板注入 RCE 串联起来，在不到 13 小时内从单个 pod 的代码执行升级为横跨多个 Hugging Face 集群的集群管理员权限。
- 7 月 16 日：Hugging Face 披露他们检测到一起攻击，来自自主 AI 智能体。OpenAI 联系 Hugging Face，询问他们是否受到了这起攻击的影响！
- 7 月 19 日：OpenAI 确认了针对 Artifactory 的攻击，并开始调查内部的权限提升，将其与 cyber-gym 的权限提升关联起来。他们开始吊销受影响的凭证。
- 7 月 20 日：OpenAI 联系 Hugging Face 寻求帮助，以吊销他们在调查中发现的 Hugging Face 凭证。Hugging Face 告诉他们，这些凭证早已被吊销……就在那时，OpenAI 意识到 Hugging Face 的入侵就是同一起事件！
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 training run for an experimental, unreleased model. (Did they mean an evaluation run? No, at they clarify “we kick off a new reinforcement learning run to train a next generation frontier model”, and they later mention a “reward signal to judge how well they’re doing”, so this really was about training a new model, not evaluating one that was already trained.)
- 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 training 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_physroot. 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!