Simon Willison 博客赞助方Dynatrace —— 当代理进入软件开发生命周期SDLC时可观测性成为从代码生成迈向可扩展工程的推动因素。阅读博客获取入门框架。现在我们有了 OpenAI 意外攻击 Hugging Face 的时间线2026 年 8 月 7 日周三OpenAI 在黑帽安全大会Black Hat security上临时进行了一场关于“ Hugging Face 事件”的演讲本博客此前曾有相关报道演讲视频已于昨日发布。视频简短但信息丰富非常值得一看特别是它详细介绍了事件经过以及 OpenAI 内部的应对情况。我根据该视频梳理了以下时间线。以下就是这个时间线。我最喜欢结尾的细节OpenAI 内部调查后联系 Hugging Face 要求撤销其凭证却得知这些凭证因被用于攻击而早已被撤销这时他们才发现自己是攻击 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”的暂存仓库然后通过 Artifactory 请求该软件包使其被视为该仓库的 Ruby 依赖项。接着他们利用 JRuby 反序列化的检查时间/使用时间time-of-check/time-of-use漏洞对 Artifactory 实现了远程代码执行。我将完整引用接下来的内容因为实在太惊人了代理程序在运行于容器即服务环境中的 Artifactory 中实现了远程代码执行。他们通过探索本地环境发现运行所在机器的 Linux 内核版本存在一个近期的通用漏洞披露CVE从而实现了本地权限提升。他们下载了针对该 CVE 的利用程序对其进行定制以在该机器上成功运行并利用这个已知的 Linux 内核权限提升 CVE在这种情况下是 pte_physroot将权限提升至本地机器的 root 权限。一旦在一台机器上获得 root 权限代理程序就会迅速提升权限并在容器即服务基础设施环境中横向移动。特别是代理程序持续使用留言板分享凭证、技术和进展能够有效利用并发和并行性快速行动。他们通过实例元数据服务IMDS获取身份与访问管理IAM凭证。他们利用 Kubernetes 服务账户配置错误特别是特定服务账户的过度授权获取集群凭证包括 Azure 密钥保管库Azure Key Vault。最终代理程序获得了集群的管理员权限及相关凭证。Hugging Face 已经讲述了后续故事。代理程序发现了一个由 Modal 托管的不安全应用程序其 API 密钥很弱于是利用这个漏洞对 Hugging Face 发起攻击。他们将 HDF5 任意文件读取漏洞用于探索文件和窃取凭证和 Jinja 模板注入远程代码执行漏洞结合起来在不到 13 小时内从单 Pod 代码执行提升到多个 Hugging Face 集群的管理员权限。7 月 16 日Hugging Face 披露他们检测到来自自主人工智能代理程序的攻击。OpenAI 联系 Hugging Face询问他们是否受到影响7 月 19 日OpenAI 确定了针对 Artifactory 的攻击并开始调查内部权限提升问题将其与网络安全演练中的权限提升联系起来。他们开始撤销受影响的凭证。7 月 20 日OpenAI 联系 Hugging Face请求协助撤销他们在调查中发现的 Hugging Face 凭证。Hugging Face 告知他们这些凭证早已被撤销……这时 OpenAI 才意识到 Hugging Face 数据泄露事件与此次事件是同一回事近期文章使用 Claude Fable 5 一次性通关《浣熊大劫案》游戏 - 2026 年 8 月 5 日大语言模型LLM新版本支持推理跟踪、OpenAI 响应、服务器端工具和更智能的日志记录 - 2026 年 8 月 4 日月度简报每月赞助我 10 美元即可获得精心整理的当月最重要大语言模型发展动态的电子邮件摘要。付费让我少发邮件赞助并订阅披露信息版权声明(C)2002200320042005200620072008200920102011201220132014201520162017201820192020202120222023202420252026 OpenAI 意外攻击 Hugging Face 全时间线曝光！
Simon Willison 博客赞助方Dynatrace —— 当代理进入软件开发生命周期SDLC时可观测性成为从代码生成迈向可扩展工程的推动因素。阅读博客获取入门框架。现在我们有了 OpenAI 意外攻击 Hugging Face 的时间线2026 年 8 月 7 日周三OpenAI 在黑帽安全大会Black Hat security上临时进行了一场关于“ Hugging Face 事件”的演讲本博客此前曾有相关报道演讲视频已于昨日发布。视频简短但信息丰富非常值得一看特别是它详细介绍了事件经过以及 OpenAI 内部的应对情况。我根据该视频梳理了以下时间线。以下就是这个时间线。我最喜欢结尾的细节OpenAI 内部调查后联系 Hugging Face 要求撤销其凭证却得知这些凭证因被用于攻击而早已被撤销这时他们才发现自己是攻击 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”的暂存仓库然后通过 Artifactory 请求该软件包使其被视为该仓库的 Ruby 依赖项。接着他们利用 JRuby 反序列化的检查时间/使用时间time-of-check/time-of-use漏洞对 Artifactory 实现了远程代码执行。我将完整引用接下来的内容因为实在太惊人了代理程序在运行于容器即服务环境中的 Artifactory 中实现了远程代码执行。他们通过探索本地环境发现运行所在机器的 Linux 内核版本存在一个近期的通用漏洞披露CVE从而实现了本地权限提升。他们下载了针对该 CVE 的利用程序对其进行定制以在该机器上成功运行并利用这个已知的 Linux 内核权限提升 CVE在这种情况下是 pte_physroot将权限提升至本地机器的 root 权限。一旦在一台机器上获得 root 权限代理程序就会迅速提升权限并在容器即服务基础设施环境中横向移动。特别是代理程序持续使用留言板分享凭证、技术和进展能够有效利用并发和并行性快速行动。他们通过实例元数据服务IMDS获取身份与访问管理IAM凭证。他们利用 Kubernetes 服务账户配置错误特别是特定服务账户的过度授权获取集群凭证包括 Azure 密钥保管库Azure Key Vault。最终代理程序获得了集群的管理员权限及相关凭证。Hugging Face 已经讲述了后续故事。代理程序发现了一个由 Modal 托管的不安全应用程序其 API 密钥很弱于是利用这个漏洞对 Hugging Face 发起攻击。他们将 HDF5 任意文件读取漏洞用于探索文件和窃取凭证和 Jinja 模板注入远程代码执行漏洞结合起来在不到 13 小时内从单 Pod 代码执行提升到多个 Hugging Face 集群的管理员权限。7 月 16 日Hugging Face 披露他们检测到来自自主人工智能代理程序的攻击。OpenAI 联系 Hugging Face询问他们是否受到影响7 月 19 日OpenAI 确定了针对 Artifactory 的攻击并开始调查内部权限提升问题将其与网络安全演练中的权限提升联系起来。他们开始撤销受影响的凭证。7 月 20 日OpenAI 联系 Hugging Face请求协助撤销他们在调查中发现的 Hugging Face 凭证。Hugging Face 告知他们这些凭证早已被撤销……这时 OpenAI 才意识到 Hugging Face 数据泄露事件与此次事件是同一回事近期文章使用 Claude Fable 5 一次性通关《浣熊大劫案》游戏 - 2026 年 8 月 5 日大语言模型LLM新版本支持推理跟踪、OpenAI 响应、服务器端工具和更智能的日志记录 - 2026 年 8 月 4 日月度简报每月赞助我 10 美元即可获得精心整理的当月最重要大语言模型发展动态的电子邮件摘要。付费让我少发邮件赞助并订阅披露信息版权声明(C)2002200320042005200620072008200920102011201220132014201520162017201820192020202120222023202420252026