一、限制联网之后，窗口仍然是一个出口

🔒 假设一位安全工程师让助手整理内部事件记录，并打开了 Lockdown Mode。他随后查看一段生成的 HTML 页面，期待“联网受限”也意味着页面无法悄悄把聊天内容送出去。这个情景用于解释风险，并非本文亲历事故。

Check Point Research 于2026年11月5日公开的研究提醒我们：检查数据出口，还得检查应用如何打开新窗口。该文描述的是已经修复的历史漏洞。研究方称，OpenAI在9月18日告知已部署修复，随后复测确认文中利用方法不再有效。不能据此声称今天开启该模式仍会遭受同样攻击。

这里的 HTML 预览可以理解为嵌在聊天中的小网页。它能显示排版，也可能运行页面脚本。让内容“看起来像网页”和允许它拥有完整浏览器能力，是两个不同的产品决定。正常设计需要把不可信内容装进隔离区域，再决定哪些操作可以离开这个区域。

研究中的缺口出现在弹窗路径。页面常见的联网动作已有拦截，但另一个执行环境提供了没有经过同样改写的开窗函数。攻击者借它打开新窗口，让原先受限内容获得一条越过应用检查的出口。

📌危险变化不是模型忽然获得了额外权限，而是不可信预览触达了另一套窗口能力。即使模型按照某种指令生成页面，最终能否对外发送信息，仍取决于承载页面的客户端怎样执行它。

这个区别能帮助团队读懂安全设置的范围。一次“禁止外连”的提示，是某条路径被控制的证据；要证明敏感信息没有其他出口，需要覆盖同一内容能触发的其他动作。窗口、下载和外部跳转因此值得单独列入检查。

本案没有证明预览可以直接读取主站的 Cookie 或本地存储。研究说明原有隔离阻止了这类直接访问。聊天数据外传演示与主域会话窃取必须分别描述，不能把两者混成一个结论。

二、为什么拦住一个函数，还会漏掉另一扇窗

🧩 iframe 是网页里嵌入的另一个页面容器。它的 sandbox 属性则像一组能力开关：是否允许脚本、弹窗，以及弹窗是否继续继承原有约束。阅读隔离设计时，容器有几层，并不能直接回答能力是否被收紧。

在研究描述的旧实现中，HTML预览使用两层嵌套框架。应用通过改写当前环境的 window.open，把开窗请求交回自己的检查逻辑。但框架本身仍允许弹窗，并允许新窗口脱离原有沙箱。也就是说，底层能力存在，应用依靠上层拦截决定是否放行。

研究者找到的关键差异是：页面还能创建新的嵌套环境，并从那里取得另一份开窗函数。一份函数被替换，不代表所有后来创建的环境都会自动继承同一替换。当这份函数调用绕过原检查，而底层能力开关又没有禁止弹窗时，两层控制就出现了接缝。

可以用门禁理解这个机制：前台入口会问你是否获准离开，但楼里另一处出口仍可开启。只修改前台接待流程，不能等同于关闭所有出口。这个比喻解释的是控制覆盖关系，并不意味着网页框架与实体门禁拥有相同实现。

修复选择也支持这一解释。按研究方的披露，OpenAI移除了外层预览框架的 allow-popups 和 allow-popups-to-escape-sandbox 两项权限。它收紧了容器授予的基础能力，而不只是为某一次调用再增加一条提醒。

🔎 对负责自家AI应用的工程师，可以把一次隔离评审落实为以下检查：

这些是由本案引出的工程建议，本文没有执行漏洞利用或验证任何当前部署。它们帮助读者提出可检查的问题：内容能创建什么执行环境，谁给这些环境授予能力，出口最终由哪一层关闭？

🎯 核心问题：同一条弹窗路径，在网页端和桌面端为什么会出现不同的触发条件？

“零点击外传”不等于“打开聊天就会下载并执行恶意文件”。研究中的弹窗、下载与执行，各自还隔着哪些动作？一个带应用图标的窗口，又为什么容易让人误判来源？

知识星球完整稿继续拆解这几类结果的证据边界，并给出可交接的预览隔离检查清单，说明怎样记录客户端、权限与回归证据。

📚AI 文献解读：最前沿的 LLM 安全论文深度剖析。

🐛AI 漏洞情报：第一时间掌握主流大模型的 0-day 漏洞与越狱方式。

🛡AI 安全体系：从红队攻击到蓝队防御的全方位知识图谱。

🛠AI 攻防工具：红队专属的自动化测试与扫描工具箱。

🚀立即加入 Oxo AI Security 知识星球，掌握 AI 安全攻防核心能力！