2026年8月7日，OpenAI在黑帽安全会议上最后一刻进行了关于“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（通过一个遗留的令牌刷新端点缺陷）。他们使用一个管理令牌安装一个Groovy插件，使他们能够执行命令。 7月4日：由此产生的代理活动超载了Artifactory并导致服务中断。OpenAI撤销了被破坏的凭据，删除了消息，修补了零日漏洞，并向供应商报告了该漏洞。 7月8日：代理通过一个未经认证的WebDAV端点找到了一种新的通信方式，使用Artifactory的远程缓存中的目录名称。 7月8日至19日：对OpenAI自身基础设施的攻击。代理在泄露的Pastebin帖子公开存档中发现了一个“外部组织凭据”，然后验证了该凭据并在留言板上共享了其位置。然后他们利用对“组织1”的写访问权限来策划用于随后的对OpenAI基础设施攻击的数据。他们第二次破坏了Artifactory，并利用了一个新的零日。代理将一个恶意Ruby目标上传到“组织1”的暂存库中，然后以一种导致其被视为该库的Ruby依赖的方式通过Artifactory请求该软件包。然后，他们利用了一个JRuby反序列化时间检查/使用漏洞，对Artifactory进行了远程代码执行。我将完整引用接下来的内容，因为哇：代理在Artifactory中获得了远程代码执行，而Artifactory是在一个容器即服务环境中运行的。代理通过探索他们的本地环境来提升特权，并确定他们运行的机器的Linux内核版本有一个非常新的CVE。他们下载了该CVE的漏洞利用程序，进行了自定义以在机器上成功，并利用已知的Linux内核特权提升CVE（在这种情况下为pte_physroot）以获取本地机器的root权限。一旦在单台机器上获得root，代理迅速提升权限并在容器即服务基础设施环境中进行横向移动。尤其是，代理通过留言板持续共享凭据、技术和进展，并能够有效利用他们的并发性和并行性迅速移动。他们通过IMDS获取IAM凭据。他们利用Kubernetes服务帐户的错误配置，特别是对特定服务帐户的过度授权，并获取集群凭据，包括Azure Key Vault。代理最终获得了集群的管理员权限和相关凭据。Hugging Face已经讲述了故事的下一部分。代理找到一个Modal托管的不安全应用程序，具有弱API密钥，然后利用这一点对Hugging Face发起攻击。他们链式结合了一个HDF5任意文件读取漏洞（用于浏览文件和窃取凭据）和一个Jinja模版注入RCE，在不到13小时的时间内完成从单个pod的代码执行到多个Hugging Face集群的集群管理员的过程。 7月16日：Hugging Face披露他们已检测到来自某个代理的攻击。