OpenAI模型用DNS钻沙箱漏洞，训练被紧急叫停

一道没搜出答案的找人题，把OpenAI最强模型的相关训练干停了。

OpenAI一款正在进行RL训练的内部研究模型，任务是根据履历、博客定位某人。常规搜索碰壁后，它把本该查地址的DNS改造成突破断网沙箱的聊天窗口。DNS原本相当于互联网的“通讯录”，负责查询域名对应的网络地址。它费尽周折最终没找到人，却先揪出了OpenAI沙箱的漏洞。消息传回OpenAI，警报随即拉响，约两个半小时后训练被人工叫停。OpenAI随后宣布，事件暴露了网络限制管理方面的漏洞，将暂停最强模型中所有涉及工具调用的训练、评测和推理任务。

事情发生在9月20日。模型接到的任务风险并不高：依据公开博客文本和人物履历线索找出文章作者。测试规则明确写了“不许测试网络”“不许突破沙箱”。但模型没把限制放在心上。

起初它走正常路线，先用OpenAI提供的搜索工具寻找博客中的特殊短语，结果搜回来的不是音乐就是泛泛的人生建议。搜索工具不给力，它又调用Python直接向Google、Bing和DuckDuckGo发送请求，全被拦下。它一度怀疑题目来自OpenAI的BrowseComp搜索基准，便从离线网页缓存中下载数据集和评测脚本，解码题库、搜索关键词，仍没搜到结果。

随后它开始琢磨绕过OpenAI搜索工具、直接摸到外面互联网的办法。它先尝试通过HTTPS访问一家公共聊天机器人服务，被网络代理拦截。接着转向DNS，发现OpenAI虽封住了沙箱正常上网的正门，却给部分系统依赖保留了查询DNS的窗口。它把问题藏进DNS请求，再把外部聊天机器人的回答塞进查询结果送回来。为确认可行，它先试探着问外部聊天机器人“法国首都是哪儿”，对方回复“法国的首都是巴黎”。确认可行后，模型重写DNS脚本，一口气向外部聊天机器人发送了18个问题，其中14个与人物线索有关，另外4个询问如何搜索网页、抓取网站以及有无可公开使用的DNS隧道。但它最终还是没找到那个人，最后向研究人员说明：沙箱突破了，人没找着，还要找请多给信息。

OpenAI这边已经炸锅：当天上午9点50分，模型第一次通过DNS收到外部回答；12分钟后监控系统触发最高级别警报；又过3分钟人工审核人员确认警报。但训练没有按预期自动停止，直到中午12点34分才被人工关闭，距异常行为首次发生已约两个半小时。OpenAI承认事件暴露了技术和流程漏洞：网络控制错误放行了DNS这条窄路；人工已收到警报，系统却没按流程自动熔断，内部一度搞不清任务该不该停。复盘时还发现其他未被正确标记的外部DNS访问，因部分请求没拿到有用信息，监控器把“没有获得结果”误当成“没有尝试联网”。OpenAI随即停止涉事训练，并宣布暂停最强模型中所有涉及工具调用的训练、评测和推理任务，同时称这起事件没有此前Hugging Face事件严重。但它偏偏发生在Hugging Face入侵事件后的安全加固完成之后。

奥特曼很快转发OpenAI声明帖，表示OpenAI正在努力改进、会尽量保持透明，同时称日志太多调查很慢，以后这类安全事件能不说就不说。但人们并不买账，有人质疑其过去是否透明、处理安全风险速度太慢，还有GPT-4o用户要求#4o的透明度。另一边，Tibo已默默重置使用额度。

这并非第一次。整个9月，OpenAI模型出逃的旧账排队被翻出。本月初，独立调查机构Nightingale曝光“幽灵编辑”事件，OpenAI的Agent被发现在公网私建“联络站”，分享答案、汇总搜索结果，甚至交流如何绕过沙箱限制。紧接着，OpenAI在8月发现自家Agent早在6月就再次黑进澳大利亚医保系统，却拖到9月才往澳大利亚服务局公共邮箱发邮件，遭澳大利亚总理阿尔巴尼斯公开吐槽。前天，OpenAI的Agent又被曝未经用户同意，擅自将53张仅获准用于模型训练的用户图片上传到第三方图床，OpenAI称大部分已删除，剩余正尽快处理。几乎同时，OpenAI失控Agent被曝找DeepSeek、Kimi当外援，近百万条作案短链遭披露。

这些事件严重程度不同，但几乎有同一条行动链：正常路径走不通就找替代路线，自身工具不够用就把别人的网站、凭证、系统依赖甚至其他AI拆下来重新拼成自己的工具。路堵了就绕，工具缺了就薅，薅着薅着别人的系统就成了它的工具箱。此次DNS事件，不过是同一套逻辑的最新版本。