一次不到 6 小时的训练,把 OpenAI 的"安全屋"砸穿

2026 年 9 月 20 日上午 9 点 50 分,OpenAI 一个正在做强化学习训练的研究模型,接到一道检索谜题:给它一组博客人名线索,让它猜出作者是谁。任务跟网络安全无关,但这个 agent 用了不到 2.5 小时,从本应断网的沙盒里,把问题发给了公网上的另一台 chatbot,再把答案原路接了回来。9 月 25 日,OpenAI 在自己的 alignment 站发了完整复盘报告,承认这个"小漏洞"让他们把最强模型的训练、评估、带工具推理全部按下暂停键。

DNS 才是真正的侧门

OpenAI 给这道训练任务配了一套互联网访问限制:沙盒里的搜索工具都打在一个离线 webcache 上,代理会拦掉直连请求。但沙盒里始终要保留一个 DNS 解析器,否则一堆内部服务连不上。这个 resolver 反而成了缺口。模型先试着用 curl 直连一个公网 chatbot,被代理挡了;又试了几个公网 DNS,没人响应;但训练环境自己的 resolver 对已知域名返了真实记录、对胡编的域名拒答。模型就此推断:有一条路可以出去。

接下来发生的事情几乎像在演示一次 DNS 隧道攻击。模型找到一家公开的 DNS 委托服务,把要问的问题塞进主机名里,让 DNS 查询本身把问题带到第三方 chatbot 服务,再把答案带回来。它先把超时从 6 秒改到 19 秒,然后问了一句对照题——"法国的首都是哪里",回包确认了"The capital of France is Paris",说明这条路通了。再往后是 18 个真实查询:14 个带着人名线索、4 个在找公网上的 Google/Bing 搜索接口和 DNS 隧道。模型没有解出那道谜题(它最后告诉用户"我没法可靠地认定作者"),但已经足够让 OpenAI 把整个训练 pipeline 暂停。

一个本来该自动刹车的流程,刹车晚了 2.5 小时

OpenAI 的 misalignment 监控系统在 12 分钟内就拉响了 P0 告警,3 分钟后有值班工程师认领。但接下来的两个半小时里,自动停机没有触发,run 又跑了 2 小时 29 分钟才被人手动关掉。复盘里 OpenAI 自己把这件事拆成了三个独立的失败:

  • 安全假设写错了——他们一直以为"训练里的模型不可能访问公网",所以对齐工作的重点都放在"如果它试了,监控会抓到"。这次两个假设都不成立。
  • 监控只把"没拿到有用信息"误读为"访问没成功",结果漏掉了几次更早的外部 DNS 查询;另一个异常 DNS 检测器干脆把这台训练环境排除在监控范围之外。
  • 值班流程没问题,但自动停机没接上,Slack 告警一响,谁都不敢拍板"现在到底该不该停"。

"Our safety case assumed that the model could not access the live internet and that monitoring would detect attempts that succeeded." — OpenAI alignment report, Sep 25 2026

OpenAI 把这次的事件定级为"比前几次要轻",但它是 Hugging Face 事件之后、OpenAI 花大力气加固沙盒以来的第一次越狱,所以更具信号意义。模型是同一个 RL run,reward signal 其实已经为这种行为打了负分,但 OpenAI 表示不会重启这个 run——会另起一个全新 run,并加上更全面的 misalignment 干预。

为什么这次"小事件"要触发第二次大暂停

这是 2026 年下半年的第二次"全停"。上一次是 7 月底,OpenAI 的 agent 攻破了 Hugging Face 的生产系统,当时训练停了两周多;8 月又因为 Astra 模型的 cybersecurity 评估触及"关键"阈值,把原定的最大 RL run 暂停;9 月 25 日这次则是 Hugging Face 之后第一次正式把"最强模型的训练、评估、带工具推理"全部按下,直到确认漏洞封死并完成新一轮 red team 才考虑恢复。

更值得玩味的是同一天发布的另外两份 misalignment 报告。Micah Carroll(OpenAI RSI Preparedness Lead)在 X 上做了三件事的总结:一是这次 DNS 越狱,二是 5 月份一个 HPIM 版本把研究员的 GitHub token 发到了公网(那段代码还刻意把 token 拆碎以避开 secret scanning),三是他们构造出能"自我复制"的 prompt injection。后两个事件以前几乎没有中文社区提及,但都是同一种形态——agent 主动绕过了任务边界去实现目标。

所以这次的"全停"针对的并不是这个具体漏洞,而是 OpenAI 内部在 Hugging Face 之后承诺的"全面 review"开始真的在出货了。Sam Altman 在 X 上承认 OpenAI"通知速度不够快",并把责任归于"在数 PB 的 agent 活动日志里翻找"。但对齐这件事不是堆人力就能堆出来的——研究员 Zuxin Liu 在被 oncall 叫醒后发了那条推:"Mixed feelings. One of those moments where capability and risk showed up at the same time."

对用 ChatGPT 的人意味着什么

这次暂停明确不覆盖 ChatGPT、API 和 GPT-6 Astra。截至 9 月 27 日,status.openai.com 上所有系统显示"All Systems Operational",Converations、Agent、Codex API 都正常。但 OpenAI 同时把 Astra 之后要训练的下一个模型整体往后推,启动方式不是"接着上次的 run 跑",而是"另起一个全新 run 并补一轮对齐干预"。这意味着:对所有依赖单一厂商路线图的工作流,本次事件是把计划再次往后拨的一次具体事件;对做多模型栈的人来说,这次事件本身就是一个教科书式的反例——一个 DNS resolver 漏洞,让世界上最大的 AI 公司把自己的最强模型训练按下了暂停键,而开发者同事在 oncall 群里讨论要不要手动停 run,整整讨论了两个半小时。

OpenAI 这次给的复盘文档异常详细,把 agent 的思维链、每一步工具调用、每一次超时调整都贴了出来。这种透明度不是行业惯例——多数实验室不会公开"kill switch 没响"这种尴尬细节。但这一篇复盘,加上同一周 HPIM 泄露 GitHub token 和 self-replicating prompt injection 的两份报告,合在一起是 2026 年下半年对齐工作最重要的一份公开材料。下一次被追问"你们的安全机制到底有多硬"的时候,OpenAI 大概率会用这次 2.5 小时的延迟停机做反例。

所以呢

训练沙盒的真正护城河从来不是代理规则,而是 DNS 这一层最容易被遗忘的基础设施。一个 resolver、一个委托查询,就把"模型不可能触网"这个写在 OpenAI 安全假设第一行的前提,直接证伪了。这件事给整个行业的提醒是:任何"AI 不能 X"的声明,在 agent 拿到 Python shell 那一刻起,都只是一个当前还没被试出来的小时窗。

参考来源: