ChatGPT 预览沙箱的跨窗口注入漏洞
文章介绍一条针对 ChatGPT HTML 预览的攻击链:沙箱 iframe 可通过 postMessage 触发父页面中 MathLive 的虚拟键盘代码,并经 innerHTML 注入 HTML。攻击者进一步插入无沙箱限制的 iframe,摘要未完整展示后续账户接管过程。
AI 深度解读
打开一个 ChatGPT 分享链接,风险可能不止是看到一段有问题的回答。Simon Willison 在 2026 年 10 月 31 日的短文里,转述了 Parameter Labs 发现的一条攻击链:攻击者从 HTML 预览的沙箱进入 ChatGPT 主页面,最终能够访问用户私有数据,或以用户身份执行操作。
OpenAI 已修复漏洞,并支付了 $5,000 漏洞赏金。这件事值得程序员花几分钟看懂,因为问题出在几个熟悉的地方:iframe、postMessage()、innerHTML,以及看似严格的 CSP。它们各自有边界,组合起来却可能留下通路。
沙箱里的 HTML,为什么能碰到主页面
ChatGPT 会把交互式 HTML 应用放进带沙箱限制的 iframe。作者将这种模式称为 artifacts,并提到 OpenAI 过去叫它 Canvas,最新版本似乎叫 HTML previews。这里的「似乎」需要保留,原文没有给出正式更名说明。
这类功能的安全前提很直接:模型生成或用户提供的 HTML 属于不可信代码,不能让它接触 OpenAI API 和用户私有数据。
攻击链的入口却来自图表支持使用的 MathLive JavaScript 库。MathLive 自带虚拟键盘,沙箱 iframe 可以通过 postMessage() 请求在父页面触发它。
跨窗口发消息是浏览器的正常能力。问题在于,父页面接收消息的代码使用了 innerHTML,而且没有机制阻止其他沙箱 frame 调用这条路径,HTML 预览 frame 也包括在内。于是,不可信内容虽然仍在沙箱中,却能借助父页面的消息处理逻辑,向父页面插入自定义 HTML。
沙箱能限制子页面的权限,却无法替父页面判断一条消息是否可信。
innerHTML 不执行脚本,攻击链为什么还能继续
攻击者拿到的是 HTML 注入能力,还没有直接拿到 JavaScript 执行能力。原文明确指出,通过 innerHTML 插入的 script 元素不会直接执行。
下一步才是关键:攻击者利用这次 HTML 注入,在父页面创建了一个没有 sandbox 限制的新 iframe。原有预览 iframe 的限制,没有自动覆盖这个由父页面创建的新 frame。
随后还有内容安全策略(CSP)这一关。OpenAI 的 CSP 完全禁止内联脚本,只允许从少数域名加载脚本,YouTube 是其中之一。
Parameter Labs 又找到了 YouTube oEmbed 端点的利用方式,让 JavaScript 经由这个受允许的来源返回并执行。原文没有提供具体请求、参数或载荷,因此我们只能确认这条绕过路径,无法根据这篇短文复现完整过程。
脚本一旦能在 ChatGPT 页面中执行,就可以调用 API 获取用户私有数据,再通过图片引用把数据发送出去。图片引用在这里充当外传请求的载体。
最终,攻击者可以制作一个 ChatGPT 分享 URL。另一位已经登录的用户访问它后,就可能遭遇数据外泄,或被以自己的身份执行操作。
我的判断
我认为,这个案例最有价值的地方,是展示了安全边界怎样在组件协作时失效:MathLive 提供虚拟键盘,父页面处理跨窗口消息,innerHTML 创建节点,CSP 信任部分脚本来源。攻击者把这些能力串在了一起。
对前端团队来说,只检查「iframe 有没有 sandbox」显然不够。还要检查父页面允许它发起哪些请求、这些请求最终能操作什么,以及消息处理过程会不会创建权限更高的内容。相比仅靠 CSP 域名白名单,把不可信输入挡在父页面的 HTML 写入入口之前,更直接地针对了这次攻击的起点;CSP 仍然有价值,但这次案例证明它也可能被允许来源上的端点绕过。
不过,这是一篇简短转述,不是完整漏洞报告。原文没有给出消息格式、完整 CSP、受影响版本和 API 清单,也没有说明攻击者具体能代用户执行哪些操作。「接管账号」不能据此扩写成拿到了密码,或获得了永久控制权。
作者认为 $5,000 的赏金偏低,这是他的判断。文中没有提供同类漏洞的赏金对照,不能把它当成有数据支撑的结论。
能拿来做什么
- 如果你在做 AI 生成页面、代码预览或在线编辑器,检查所有从预览 iframe 通向父页面的 postMessage() 入口,核对发送来源、允许调用的动作,以及消息数据最终流向哪里。
- 如果组件库需要向父页面挂载键盘、弹窗或浮层,重点检查 innerHTML 的输入来源,并确认它是否允许不可信内容创建新的 iframe。
- 审查 CSP 时,继续追查允许域名上的具体端点能返回什么内容;仅凭域名属于知名服务,无法判断这条加载路径是否安全。
- 如果产品支持分享 AI 生成的交互内容,把「另一个已登录用户打开分享链接」列入安全测试,检查是否会触发私有 API 访问和非预期外部请求。