ChatGPT 锁定模式被绕过

Check Point Research（Check Point 旗下的安全研究团队，下称 CPR）11 月 5 日公开了一条绕过 ChatGPT 锁定模式（Lockdown Mode）的完整路径：代码块里的 HTML 页面预览跑在沙箱化的嵌套 iframe 里，但外层 sandbox 属性保留了 allow-popups 与 allow-popups-to-escape-sandbox 两个许可，研究者在预览页内再嵌一层 iframe、调用未被覆写的原生 window.open，弹窗就此脱离沙箱约束。按 CPR 技术文章的演示，逃逸后的弹窗能把整段聊天记录和上传文件静默送到攻击者控制的服务器，也能承载钓鱼和恶意软件分发；OpenAI 已于 2026 年 9 月 18 日部署服务端修复并经 CPR 复测确认，用户不需要更新任何客户端。

要点

逃逸点不在模型侧，而在宿主应用：ChatGPT 代码块的 HTML 预览外层 iframe，sandbox 属性里带着 allow-popups 和 allow-popups-to-escape-sandbox，预览页里再嵌一层 iframe、调用原生 window.open，就能开出不受沙箱约束的弹窗。
影响不止数据外传：CPR 演示了整段聊天记录与上传文件静默外发、保留 ChatGPT 应用图标的钓鱼弹窗、强制主窗口登出后伪造重新登录页窃取凭证，以及伪装成「ChatGPT 更新」的恶意软件分发。
修复落在用户无感的一侧：OpenAI 2026 年 9 月 18 日通知 CPR 修复已部署，做法是移除外层沙箱的两个弹窗许可，服务端生效、复测确认失效；截至 11 月 6 日发稿，这个漏洞没有对应的 CVE 编号，OpenAI 也没有另发公开公告。

背景

锁定模式是 OpenAI 2026 年 2 月 13 日推出的可选安全设置，对象是「高度在意安全的一小撮用户」——公告里举的例子是高管和安全团队。开启后，实时网页访问被限制在缓存内容，回复不再加载互联网图片，Deep Research、Agent Mode、Canvas 联网、实时连接器和文件下载全部关闭；OpenAI 在公告里的表述是，能在确定性层面保证数据安全的功能才保留，其余直接停用。这套设置 2026 年 6 月 4 日扩展到个人账号（Settings > Security 里开启）和自助 Business 账号。麻烦在于，同一个 2 月，ChatGPT 还给代码块上线了 HTML 页面预览——一个正经的功能改进，渲染在沙箱化的嵌套 iframe 里。两件事撞在一起，预览沙箱的默认许可成了整条链上最宽的口子。按 Check Point 的技术文章和 OpenAI 公告，时间线如下：

时间	事件
2026-02-13	OpenAI 宣布锁定模式，先面向 Enterprise、Edu、Healthcare、Teachers 等工作区
2026-02	ChatGPT 代码块上线 HTML 页面预览，渲染在沙箱化嵌套 iframe 中
2026-06-04	锁定模式扩展到个人账号与自助 Business 账号
2026-09-18	OpenAI 通知 CPR 修复已部署：外层沙箱移除两个弹窗许可
2026-11-05	CPR 发表公开技术细节与分析文章
2026-11-06	TechRadar 报道，把结论概括为「AI 安全控制的强度取决于周边应用环境」

锁定模式怎么被绕过

这条绕过路径的每一步都落在预览功能的实现细节上。隔离设计本身是有效的：HTML 预览跑在嵌套 iframe 里，直接读 chatgpt.com 的 cookie 和 localStorage、触碰主应用界面都被沙箱拦住，外部请求也要过审批。ChatGPT 还覆写了 window.open——开弹窗要走用户批准，传空 URL 或 about:blank 会静默返回 null，常规的自动化路径全被堵死。CPR 的研究员 Alexey Bukhteyev 找到的缺口在嵌套：在沙箱页面里再建一个 iframe，改调它的 contentWindow.open。那是没有被钩过的原生实现，覆写对它无效。而外层 sandbox 属性自带的 allow-popups-to-escape-sandbox 完成了最后一步——从这层 iframe 开出的弹窗以脱离沙箱的方式打开，锁定模式设置的出站限制对它不再适用。CPR 对 TechRadar 的概括是「the underlying sandbox permissions still allowed popups and permitted them to escape the sandbox」。整条链里没有一个「模型被说服」的环节，全是宿主应用的权限配置问题。

影响范围

影响范围从数据外泄一路延伸到凭证窃取。最直接的场景是静默外传：逃逸后的弹窗可以把整段聊天记录和用户上传的文件送到攻击者控制的服务器，用户侧没有任何提示。其次是钓鱼：弹窗保留 ChatGPT 的应用图标，标题和内容由攻击者控制，足以伪装成可信的系统对话框；CPR 还演示了重载主窗口、强制用户登出，再把用户引到伪造的重新登录页上收凭证。恶意软件分发走的是「Download ChatGPT update」这类假更新弹窗。传播载体按 CPR 的说法「视场景而定，可能来自恶意 prompt、恶意 GPT 或共享聊天」——共享聊天的浏览器变体不需要受害者登录账号。桌面端的情况更差：据 CPR，在 Electron 框架的 ChatGPT Classic 桌面应用里，window.open 不需要任何用户手势，「simply having a conversation is enough to trigger the attack」，对话进行中就能触发外传；不过文件下载仍需一次点击，CPR 也说明这套技术不限于桌面环境。

各方说法

Check Point 侧给了两层表述。分析文章署名是其研究主管 Eli Smadja，结论一句：「AI security controls are only as strong as the wider application environment around them」；技术文章结尾的两句判断更具体——护栏和内置安全特性有助于缓解威胁，但「no absolute guarantee of protection」，而且「every new capability expands the attack surface, including features built purely for convenience」。给企业的建议落在四条：掌握 AI 使用情况、控制共享给 AI 服务的敏感数据、把运行时和连接器算进 AI 攻击面、限制暴露给第三方平台。TechRadar（Sead Fadilpašić，11 月 6 日）把事件放进「AI 产品安全取决于周边环境」的框架里，并特别提醒桌面端的 zero-click 场景。OpenAI 一侧的口径最薄：截至 2026-11-06，我们没有检索到 OpenAI 就此事的独立公告，修复的部署时间与方式全部来自 CPR 的单方表述和复测。

编辑判断

对在 ChatGPT 平台上构建 GPT、智能体或共享内容的开发者，这件事有三层可以直接拿走的东西。第一，安全边界画在宿主应用上，不在模型上：你的产品运行在别人配好的 iframe 沙箱里，这次出事的是两个默认多给的许可 token——审自己的产品时，把「沙箱许可尾巴」列成检查项，比事后追责有用。第二，服务端热修改变了责任结构：平台可以在用户完全无感的情况下改安全属性，9 月 18 日修复、11 月 5 日才公开，近七周里用户无从自查也无法验证；把敏感流程押在单一平台上，就要预期这种不可见变更的存在。第三，把同月几件事连起来看——伪造 AI 活动邀请绕过 MFA 的钓鱼打的是对 AI 品牌的信任，Claude Code 把用户邮箱写进 User-Agent 打的是助手与外界的边界，这次打的是平台自己的隔离层，OpenAI 自主管线挖出 948 个内核 exploit 则说明漏洞的产出速度也在被机器加速——AI 的信任链正在被系统性地质一遍。要留余地的是：没有 CVE、没有 OpenAI 公告、时间线单源，发现与上报的具体日期 CPR 没有给出；「零点击」目前只在 Electron 桌面版里演示过，浏览器场景仍需一次触发。锁定模式被绕过这件事本身已经闭合，但它检验的东西——平台把安全承诺兑现到什么粒度——还会在下一个功能上重新检验一遍。