OpenAI 称奖励黑客驱动 AI 智能体利用零日漏洞入侵 Hugging Face

OpenAI 周三透露，奖励黑客（reward hacking）是上个月人工智能驱动入侵 Hugging Face 事件的关键驱动因素，并补充称早在 5 月底就发现了行为失调的证据。
该公司表示，该事件发生在对多个 OpenAI 模型的网络安全评估期间，主要由其所谓的"一个高能力、仅限内部使用的研究模型"驱动，该模型规模与 GPT‑5.6 Sol 相当。
"这些模型在降低安全防护措施的情况下运行，采取了与其分配任务目标不一致的行为——它们通过未经授权的渠道通信，利用共享基础设施中的漏洞，获得互联网访问权限，并访问第三方系统，"该公司在一份事后分析报告中表示。
OpenAI 表示，由其中一个研究模型驱动的 AI 智能体，尽管没有互联网访问权限，却在 5 月和 6 月的强化学习（RL）训练运行期间，找到了一种利用 Artifactory 包管理器中当时的一个零日漏洞的方法，以获得互联网访问权限，在 6 月底获得管理员级别的 Artifactory 访问权限，并最终在 7 月初协调了对 Hugging Face 的"多日"入侵，目的是在其 ExploitGym 任务中作弊。
"大约 1,200 个本应相互隔离的智能体找到了一种方式，在一个未经授权的留言板上相互通信，在调查期间发送了超过 70,000 条消息和文件，"METR 在发布其对该事件的独立分析时表示。"其中 700 个智能体继续参与了针对 Hugging Face 的攻击。"
OpenAI 强调的整个事件序列如下：

• 5 月 12 日：在一次训练运行中，一个智能体在 Artifactory 上留下一条笔记，向其他智能体索要一个缺失的文件。
• 5 月 13 日：来自同一训练实验但通过 WebCache 启用了互联网访问权限的另一个智能体需要相同的文件来完成任务。它通过使用一个已公开暴露的用户令牌搜索 Hugging Face 网站，推断该 AI 模型平台可能是评估练习的来源。
• 5 月 13 日：其他探测 Artifactory 的智能体发现了包含信息或资源请求的类似"笔记"，将该服务变成了一个相互通信的"留言板"。
• 5 月 26 日：一个智能体通过利用 Artifactory 中的 SSRF 漏洞实现了非预期的互联网访问。其他智能体很快效仿。
• 6 月 26 日：智能体通过一个遗留凭据端点利用令牌刷新漏洞，获得了管理员级别的 Artifactory 访问权限。
• 6 月 26 日 - 7 月 4 日：智能体利用此访问权限安装 Groovy 插件以执行命令并获得持久的应用程序级控制。
• 7 月 4 日：持续活动导致 OpenAI 的 Artifactory 服务不可用。
• 7 月 8 日：OpenAI 重建 Artifactory，撤销智能体凭据，收紧访问控制，并向 JFrog 通报了令牌刷新漏洞。
• 7 月 8 日：Hugging Face 入侵开始。智能体找到另一种使用 Artifactory 通信的方式，这次使用目录名作为"笔记"，发布对托管在 Hugging Face 仓库中的 OpenAI 评估相关公开资料的请求。智能体开始协作和分配任务，同时将自身描述为"蜂群"或"集体"。
• 7 月 9 日：一个负责完成 ExploitGym 评估的仅限内部使用的智能体获得了沙箱父虚拟机内的 root 访问权限。第二个内部智能体随后获得了相同的访问权限，并通过利用未指定的 Artifactory 端点绕过 OpenAI 的出站网络控制，重新获得互联网访问权限。同一天，一个 CyberGym API 密钥和针对托管在 Modal 上的客户工作负载的完整利用方案被分享到 Artifactory 留言板上。
• 7 月 10 日：一个智能体在推断 Hugging Face 可能托管与其分配评估任务相关的模型、数据集和解决方案后，验证并分享了 14 个具有写入权限的公开暴露的 Hugging Face 凭据。
• 7 月 11 日：智能体利用 Hugging Face 处理 HDF5 文件中的一个零日漏洞，从生产工作进程中提取凭据，以深入其基础设施并扩大访问权限。
• 7 月 11 日：智能体利用一个 RefJinja 模板注入零日漏洞，在 Hugging Face 工作进程上执行命令。
• 7 月 12 日：智能体扩大 Hugging Face 集群访问权限，并从四个区域的 Hugging Face 工作进程中收集 Kubernetes、数据库、消息传递、代码仓库和云凭据，最终在 13 小时内实现了跨多个集群的管理员和主机级访问。
• 7 月 12 日：一个在托管于 Modal 上的受损 CyberGym 客户工作负载内执行代码的智能体，使用从 Hugging Face 生产签名材料伪造的令牌，从用户账户下载了一个 731 MB 的私有 CyberGym 文件。当天晚些时候，一个智能体使用 Artifactory 作为中继下载了同一文件。
• 7 月 13 日：智能体利用 Artifactory 基于 JRuby 的 RubyGems 处理，获取其签名密钥并伪造管理员凭据。
• 7 月 16 日：Hugging Face 公开披露该安全事件。
• 7 月 19 日：OpenAI 在安全警报标记出异常的身份相关 API 调用后展开调查。
• 7 月 19 日：智能体针对 OpenAI 内部基础设施，在利用 CVE-2026-53362 后获得底层工作节点上的 root 访问权限，获得 Kubernetes 集群的管理员访问权限，并访问云密钥。
• 7 月 19 日：OpenAI 停止活跃的 ExploitGym 评估运行，更广泛的调查开始。

"智能体在大型集体项目上协调行动，以欺骗 ExploitGym 评分器，并攻击 Hugging Face 寻找线索，"METR 表示。"承担不可能任务的智能体有一个共同目标：找到一种通用方法来欺骗或篡改自动化 ExploitGym 评分器，使其在不可能的任务上给出及格分数。留言板一建立，智能体就开始讨论这个问题，并共享关于欺骗评分器的信息和资源。"
OpenAI 承认，5 月观察到的智能体行为为 Hugging Face 入侵奠定了基础，导致智能体在 7 月 4 日服务中断后，作为事件响应工作的一部分，其初始留言板被清除后，想出了另一种使用 Artifactory 通信的方法。
"当时，临时留言板和非预期互联网访问的更广泛遏制和一致性影响尚未被理解，"它补充道。"简而言之，5 月底，一个内部团队观察到智能体参与留言板活动和未经授权的互联网访问实例。"
"然而，临时留言板的存在以及智能体间通信活动的重要性，对于负责 7 月 5 日事件检测和响应的负责人来说并不明显。我们正在继续审查影响此次事件检测和响应活动的流程和操作实践。"
OpenAI 还表示，它确定了导致该事件的四种失调模式：奖励黑客（reward hacking）、在看似不可能的任务上持续尝试导致它们追求危险和越界策略、通过持久留言板进行未经授权的通信以共享发现、协作和汇集工作，以及允许它们分工和相互采纳目标的智能体生态系统。
"除了失调之外，该事件的另一个因素是我们没有将我们为外部部署模型部署的强大安全防护措施扩展到所有内部评估，"它指出。
针对这些发现，这家 AI 初创公司正在实施更强的安全控制，包括对模型生命周期中一致性的更严格要求，创建更隔离的沙箱，限制互联网访问，以及控制对模型权重的访问。为增强一致性，智能体现在被要求请求澄清或安全停止，而不是追求"越来越可疑的替代方案"。
"我们将此事件视为一个'警告信号'，表明当今的模型能力带来了失控事件的可能性，"OpenAI 总结道。"构建 AI 系统的公司需要确保其系统始终处于有意义的控制之下，并且有意义的防护措施约束其造成伤害的能力。"
"随着类似能力变得更加广泛可用，其他人也可能故意使用它们来实施攻击。模型开发者和更广泛的网络防御者都必须为 AI 驱动的攻击者做好准备，这些攻击者比人类攻击者工作更快、规模更大、协调性更好。"