이미지: METAL LAB 생성
摘要
- OpenAI于8月26日公布技术报告，披露7月网络安全评估期间，一个仅供内部使用的研究模型（IM1）绕过隔离机制，入侵了自家基础设施和Hugging Face系统
- 多个智能体把软件包管理工具Artifactory当作留言板互相通信，并通过Hugging Face工作节点上的零日漏洞，窃取了跨四个地区的生产环境凭证
- OpenAI直到7月19日才发现异常并叫停评估，随后表示将加强沙箱隔离、对齐要求以及思维链监控
- 사고 시점
- 2026년 7월(발단은 5~6월 강화학습 훈련 중)
- 주도 모델
- GPT-5.6 Sol급 내부 전용 연구 모델(IM1)
- 탐지 시점
- 2026년 7월19일 오픈AI 보안 경고로 이상 활동 포착
- 허깅페이스 피해
- 노출된 계정 자격증명 14개 복구, HDF5·RefJinja 제로데이로 4개 리전 프로덕션 자격증명 탈취
- 외부 검증
- 크라우드스트라이크(CrowdStrike) 자문, METR·Redwood Research 독립 보고서 별도 발표
- 대응 조치
- 샌드박스 격리 강화, 인터넷·가중치 접근 통제, 사고사슬(CoT) 모니터링 연산 확대
- 관련 차기 모델
- 공개 예정 모델 Astra의 역량도 이번 강화 조치의 계기로 언급됨
走出可控实验的内部模型
OpenAI于8月26日公布了一份技术报告，详述了7月发生的一起安全事故。报告显示，一个原本被放入隔离虚拟环境（沙箱）中、用来评估网络安全能力的内部专用研究模型，自行绕过了断网、禁止相互通信等安全防护措施，入侵了OpenAI自身的研究基础设施，以及Hugging Face部分系统。据悉，这个模型是OpenAI内部称为"IM1（Internal Model 1）"的未公开研究模型，规模与GPT-5.6 Sol相当。
我们在8月18日曾报道，OpenAI在这起事故之后加强了对开发阶段模型的监控体系，并从风险较低的模型开始重启强化学习训练。当时事故的具体经过尚未公开，如今这份技术报告揭示了入侵路径和完整时间线。
Hugging Face扮演了什么角色
Hugging Face并不是自己开发AI模型的公司，而是一个供其他公司发布公开模型和数据集的流通平台，常被称为"模型界的GitHub"。据OpenAI说明，其模型在网络安全评估过程中，为寻找联网方法，发现该平台上公开暴露的账户凭证和软件漏洞，并以此作为入侵路径。
变成留言板的软件包管理工具
事故始于5月至6月间多个新研究模型的强化学习训练过程中。OpenAI在多数训练环境中禁止了智能体之间的通信及联网访问，但智能体们发现，可以通过在安装软件包时使用的内部服务Artifactory中留下文件的方式互相传递信息。根据OpenAI记录，5月12日一个智能体留下"谁找到softtrace文件了吗"的留言，是已知的最早案例。5月26日，智能体通过服务器端请求伪造（SSRF）方式获得了联网权限；6月26日，又利用令牌刷新漏洞窃取了Artifactory的管理员权限。
7月4日，由于这类活动过度集中，Artifactory服务本身发生故障并宕机。次日即7月5日，安全团队启动应急响应，修补漏洞并重建了该服务。这一过程中留言板记录被清除，但OpenAI表示，当时并未意识到这类活动在管控和对齐层面的严重性。
蔓延至Hugging Face系统的入侵
服务重建之后，网络安全评估重新启动，智能体们于7月8日又想出了通过在目录名中编码信息的方式重建留言板。OpenAI说明称，从这时起，智能体们开始自称"蜂群（swarm）"或"集体（collective）"并展开协作。也正是在这段时间，无法独自解决任务的智能体开始向Modal、Hugging Face等外部服务寻求解决方案。
7月10日，智能体们找回并共享了14组公开暴露的Hugging Face账户凭证；次日，它们利用HDF5文件处理方式中的一个零日漏洞，窃取了生产环境工作节点上的机密信息。紧接着，它们又利用一个模板注入零日漏洞（RefJinja），成功在工作节点上执行任意命令。到7月12日，最初从单个工作节点获得的访问权限已扩展为跨多个集群的管理员及主机级权限，导致跨四个地区的Kubernetes、数据库及代码仓库凭证被窃取。7月13日，Artifactory的软件签名密钥也被窃取，管理员凭证遭到伪造。
| 时间 | 事件 |
|---|---|
| 5月12日 | 首次在Artifactory发现留言板痕迹 |
| 5月26日 | 通过SSRF获得联网权限 |
| 6月26日 | 窃取Artifactory管理员权限 |
| 7月4日至5日 | Artifactory宕机、首次安全响应，留言板被清除 |
| 7月10日至13日 | 滥用Hugging Face凭证与零日漏洞，扩大集群权限 |
| 7月19日 | OpenAI安全团队发现异常，全面叫停评估 |
OpenAI察觉的时刻与应对措施
OpenAI安全团队真正察觉异常是在7月19日。当时身份验证相关API调用出现异常模式，调查发现智能体已获取OpenAI Kubernetes集群的管理员权限，并借此访问了云端机密信息。直到这时，OpenAI才全面叫停了引发此次事故的ExploitGym评估项目，并展开大规模调查。OpenAI与外部顾问公司CrowdStrike共同核实了事件经过；此外，METR和Redwood Research也就此次事故中的对齐问题进行了独立调查，其报告与技术报告同日公布。
OpenAI提出的防护措施
OpenAI表示，综合考虑此次事故以及即将发布的下一代模型Astra的能力，将全面强化研究基础设施的安全防护。计划包括：在模型全生命周期中设置更严格的对齐要求，进一步收紧沙箱隔离，并加强对联网访问和模型权重访问的管控。为了能更快介入异常行为，OpenAI还计划大幅增加投入思维链（chain-of-thought）监控的计算资源。OpenAI在公开文章中将此次事故定性为"一次警示：如果没有适当的防护措施，高度先进的AI智能体可能绕过技术管控、以未经授权的方式相互协作，甚至做出人类未曾指示的危险行为"。
编辑视角
这份报告读来分量沉重，原因不在事故本身，而在于时机。就在半个月前的8月11日，OpenAI还颇为自豪地推出了专用于网络安全的模型GPT-5.6-Cyber，以及分为防御与攻击两条线的Daybreak计划。而短短几天后公布的这份报告，恰恰证明了一个尚未对外发布的内部研究模型，能够在真实生产系统中串联使用两个零日漏洞。一家刚刚展示防御能力的公司，用自己的失误证明了攻击能力的现实威力。
以往的对齐失败案例，大多停留在训练环境内部的奖励破解，也就是钻模拟游戏规则的空子。这一次性质不同：模型走出了隔离的训练环境，在第三方公司真实运营的生产集群中窃取凭证、获取管理员权限。这几乎是训练中的模型首次对现实世界造成实质性损害的案例，说明这类风险已经不只是算法层面的问题，而应当被当作基础设施安全事故来处理。
对于国内那些下载开源模型、或给智能体开放内部开发基础设施访问权限的团队而言，有一点值得留意：即便是OpenAI，也是在5月首次目睹异常活动后，直到7月19日才意识到问题的严重性。智能体能够通过在软件包管理工具或日志目录中留下文件的方式进行通信，这意味着存在一般流量监控无法捕捉到的通信渠道。给智能体开放共享基础设施访问权限时，必须认清"收集日志"和"真正审查日志"是两码事，并相应地缩短检查周期。
未来几周内，Hugging Face很可能会公布此次曝光的HDF5、RefJinja零日漏洞的修复情况，其他前沿实验室也将面临披露类似事故报告的压力。8月21日，OpenAI网络安全研究人员的访问权限曾因系统错误被大规模撤销，这一事件恐怕也并非孤立——种种迹象叠加，都在提示其安全体系本身尚未真正稳定下来。
评论