一条链接，接管ChatGPT：这次漏洞击穿的不只是一个沙箱

安全研究团队 Parameter Labs 最新披露了一条完整的 ChatGPT 账户接管漏洞链：攻击者只需制作一条看起来正常的 ChatGPT 公开分享链接，受害者在已登录状态下打开后，恶意 JavaScript 就可能以 chatgpt.com 的身份运行，读取未公开的私人对话，并调用受害者有权访问的前端接口。(parameter.ai)

这不是常见的仿冒登录页，也不要求用户粘贴脚本、安装扩展、连接第三方应用或授权陌生工作区。在研究人员最终验证的自动触发版本中，受害者唯一需要做的事情就是打开链接；载荷大约在 4.5 秒后执行，并在另一账户中连续复现了 3 次。

OpenAI 已在 2026 年 10 月 26 日完成修复，并将报告定为最高优先级之一的 P1 漏洞。Parameter Labs 于 10 月 28 日公开技术细节，因此它目前不是一个仍可直接利用的零日漏洞，但其暴露出的产品安全问题，比一次普通的跨站脚本攻击更值得重视：当 AI 产品同时支持分享、代码预览、交互图表、文件和第三方组件时，安全边界不再是一堵墙，而是一组可能被意外连通的门。

漏洞到底严重在哪里

**账户接管漏洞是指攻击者能够以受害者身份读取数据或执行账户操作的安全缺陷。**这次研究没有以窃取密码作为终点，而是让攻击代码直接进入受害者已经登录的浏览器会话，相当于绕过登录环节，坐到了用户已经解锁的电脑前。

研究人员验证的实际影响包括：枚举受害者最近的对话、选择一条从未与攻击者分享的私人对话、读取其中的消息内容，并把一小段验证数据发送到外部服务器。研究团队只提取了有限数据作为漏洞证明，但同源脚本能够触达的范围并不天然局限于聊天记录，而是取决于 ChatGPT 网页前端向当前账户开放了哪些操作。(parameter.ai)

这一区别很关键。传统钓鱼通常需要用户输入密码或验证码，而这条攻击链利用的是受害者已有的认证状态；传统提示词注入主要影响模型决策，而这条攻击链最终获得的是浏览器中的 JavaScript 执行能力。它攻击的不是模型“会不会听坏人的话”，而是网页应用是否正确隔离了不可信内容。

| 攻击类型 | 用户通常需要做什么 | 攻击者获得什么 | 本次事件是否符合 | |---|---|---|---| | 仿冒登录钓鱼 | 输入账号、密码或验证码 | 登录凭据 | 否 | | 恶意扩展攻击 | 安装浏览器扩展并授予权限 | 页面与浏览器数据 | 否 | | 提示词注入 | 让模型读取恶意指令 | 影响模型行为或工具调用 | 不是核心原因 | | 跨站脚本攻击 | 打开或操作存在漏洞的页面 | 目标站点上下文中的脚本执行 | 是 | | 账户接管 | 触发漏洞或泄露认证信息 | 受害者账户权限 | 是 |

五个正常功能，拼出一条攻击链

**这次漏洞的核心不是某个功能完全失控，而是多个单独看来合理的功能被串成了攻击路径。**攻击链涉及 ChatGPT 公开分享、HTML Preview、交互图表、MathLive 数学输入组件、跨窗口通信机制 postMessage、srcdoc iframe，以及内容安全策略 CSP。

攻击从一条公开分享的 ChatGPT 对话开始。攻击者先在对话中放入一张真正的交互图表，让 ChatGPT 主页面加载 MathLive；随后再加入一个可预览的 HTML 内容，让代码运行在原本受限的 Preview 环境中。分享功能会把这两个部分一起保留下来，最终形成可发送给其他用户的 /share/<id> 链接。

**HTML Preview 是 ChatGPT 用于运行和展示 HTML 内容的隔离预览环境。**由于 HTML 可能包含任意脚本，Preview 不应与主页面处于同一安全上下文，因此 ChatGPT 把它放在不同来源的受限 frame 中。研究人员确认，Preview 不能直接读取 parent.document，说明这层基础隔离本身确实有效。

问题出在另一座连接沙箱与主页面的桥上。

**postMessage 是浏览器允许不同窗口或 frame 交换消息的跨文档通信机制。**它像一个安装在隔离墙上的投递口：沙箱里的页面无法直接走进主页面，却可以向主页面发送一封结构化消息。这个机制本身很常见，但接收方必须验证消息来自哪个网站，以及来自哪个具体窗口。

MathLive 在 ChatGPT 主页面注册了一个消息监听器，用来控制虚拟数学键盘。研究人员发现，相关路径允许 originValidator 处于 none 状态，并接受能够修改键盘布局的消息；MathLive 的公开代码中也可以看到 mathlive#virtual-keyboard-message、update-setting 和 originValidator 等相关实现。其代码结构可在 MathLive 的 GitHub 源码 中查看。

漏洞的第一处关键错误是接收方没有充分验证 event.origin 与 event.source。event.origin 表示消息来自哪个来源，event.source 则表示消息来自哪个窗口；只检查消息格式而不确认发送者，就像公司前台收到一张格式正确的工单后，不核对工牌便允许对方修改内部系统。

MathLive 接收的键盘布局数据还允许包含 HTML 标记。沙箱内的 Preview 因而可以发送两条消息：第一条替换虚拟键盘布局，第二条要求显示键盘。当主页面渲染这份布局时，攻击者控制的 HTML 就进入了真正的 ChatGPT 页面。

| 环节 | 原本的安全假设 | 实际缺口 | 直接后果 | |---|---|---|---| | HTML Preview | 不同来源的 frame 无法读取主页面 | 仍可向顶层窗口发送消息 | 获得向特权组件投递数据的能力 | | MathLive 监听器 | 消息来自可信数学输入组件 | 未充分验证来源与发送窗口 | 不可信 Preview 可修改键盘状态 | | 键盘布局 | 布局只是展示数据 | 布局允许携带原始 HTML | 攻击者内容进入主页面 DOM | | srcdoc iframe | 新 frame 应继续保持隔离 | 动态创建时没有附加沙箱限制 | 新文档继承 chatgpt.com 来源 | | CSP | 非法脚本无法加载 | 白名单脚本源存在可利用响应 | 攻击代码最终得到执行 |

Trusted Types 没有完成真正的清洗

**Trusted Types 是浏览器用于限制危险 DOM 写入位置的安全机制，但它不等于自动过滤恶意 HTML。**研究人员发现，MathLive 最终把键盘布局拼接为 HTML 字符串，并写入主页面的 innerHTML；其中名为 createHTML 的辅助方法看似提供了安全包装，实际更接近一个身份转换器，没有对攻击者控制的内容进行有效消毒。

这说明“可信类型”与“可信内容”不是一回事。Trusted Types 可以规定只有某个策略创建的值才能进入 innerHTML 等危险位置，但如果策略本身把任何输入原样标记为可信，攻击面只是从“谁都能写入”变成“通过这个函数就能写入”。MathLive 后续版本的更新记录也出现过针对不可信 HTML 和 JavaScript 注入的安全修复，并使用 DOMPurify 进行清洗，相关记录可见其 GitHub Changelog。

普通的 <script> 标签通过 innerHTML 插入后通常不会自动执行，因此攻击者还需要找到第二次解析 HTML 的机会。研究人员使用了没有 sandbox 属性的 srcdoc iframe，让浏览器创建一个新的内嵌文档；由于该 frame 是由 ChatGPT 主页面创建的，它获得了 https://chatgpt.com 的来源身份，并可以访问父页面。

**srcdoc 是允许开发者直接在 iframe 属性中提供完整 HTML 文档的浏览器功能。**它非常方便，却也是容易被低估的安全边界：如果攻击者能够控制其内容，而开发者又没有添加严格的 sandbox，一个原本只是 HTML 注入的问题就可能升级为同源脚本执行。

CSP挡住了一次，却没挡住整条链

**内容安全策略 CSP 是网站用于限制脚本、图片和 frame 加载来源的浏览器安全规则。**ChatGPT 的 CSP 成功拦截了内联 JavaScript，说明这层防线并非没有作用，但策略允许加载 YouTube 脚本，而 YouTube 的一个 oEmbed 响应支持类似 JSONP 的回调形式。

研究人员利用该响应对回调参数处理不严的问题，使白名单域名返回一段可执行 JavaScript。浏览器看到脚本来自 CSP 已允许的 YouTube 域名，便在新建的同源 frame 中执行它，最终让攻击代码获得 chatgpt.com 上下文。

这里最容易得出错误结论的是：只要删除 YouTube 白名单，漏洞就解决了。实际上，YouTube 响应只是最后一段可替换的执行手段，真正的根因仍然是低权限 Preview 能够指挥主页面组件插入任意 HTML，并创建没有沙箱保护的同源文档。

CSP 更像建筑里的防火门，而不是地基。防火门可以延缓火势，但如果未经检查的材料已经被运进核心机房，就不能指望一张域名白名单解决所有问题。

从弹窗到读取私人对话

**同源 JavaScript 的危险性取决于它能继承多少用户权限。**当代码以 chatgpt.com 身份运行后，它不再需要从页面上“偷看”文字，而可以使用网页应用已有的认证环境，请求对话列表和对话详情。

研究人员先让载荷列出最近的 20 条对话，再读取其中一条与恶意分享链接无关、从未公开给攻击者的私人对话。随后，载荷通过一次普通的外部资源请求发送少量验证数据，从而证明数据已经能够离开受害者会话。

这也是“弹出一个 alert”与“账户接管”之间的差别。安全研究中的弹窗通常只用于证明代码执行位置，而真正的风险要根据代码所处的权限环境判断；在一个保存长期聊天记录、上传文件、记忆和工作资料的 AI 产品中，同源脚本执行的价值远高于普通内容网站。

OpenAI如何修复

**OpenAI 的修复重点是切断 Preview 到 MathLive 主页面监听器的跨 frame 消息路径。**Parameter Labs 称，OpenAI 在两个版本的 ChatGPT Web 前端上分阶段部署修复，并调整 CSP 以提前阻断原始攻击链的一部分；到 10 月 26 日，两套前端都已拒绝研究报告中使用的跨 frame MathLive 消息。(parameter.ai)

事件时间线显示，OpenAI 从收到报告到确认全面修复用了 8 天，从复现漏洞到部署第一版修复仅用了约 1 天。漏洞最初按 P2 分流，OpenAI 在复现 JavaScript 执行和私人对话读取后，于 10 月 21 日将其升级为 P1，最终支付的漏洞赏金为 5000 美元。

| 日期 | 事件 | |---|---| | 2026年10月13日 | 研究人员确认 MathLive 消息可将 HTML 写入 ChatGPT 主页面 | | 10月14日 | 将弹窗验证升级为任意 JavaScript 执行 | | 10月16日 | 在不同账户与工作区之间通过公开分享复现 | | 10月17日 | 验证自动 Preview 路径，打开链接即可触发 | | 10月18日 | 向 OpenAI 漏洞赏金计划提交报告 | | 10月19日 | 补充读取私人对话的受控证明 | | 10月21日 | OpenAI 完成复现，严重性由 P2 升级为 P1 | | 10月22日 | 一套 Web 前端完成修复 | | 10月26日 | 两套前端均完成修复，发放 5000 美元赏金 | | 10月28日 | Parameter Labs 公开披露漏洞细节 |

5000 美元的奖金与漏洞影响并不匹配。无论按照传统漏洞赏金项目的严重性，还是按照 ChatGPT 用户数据的敏感程度，一条可跨账户读取私人聊天、并可能执行更多认证操作的 P1 攻击链，5000 美元都显得偏低。过低的奖励未必会减少漏洞，只可能降低优秀研究人员优先向厂商负责任披露的动力。

这不是“AI又被提示词骗了”

**这次事件首先是经典 Web 安全问题，而不是模型安全问题。**漏洞没有依赖模型泄露系统提示词，也没有要求模型违反安全策略；模型和对话内容主要承担了载体角色，真正失守的是浏览器隔离、第三方组件通信和动态 HTML 渲染。

但 AI 产品放大了传统 Web 漏洞的影响。ChatGPT 不只是一个生成文本的网页，它正在逐步承载用户的长期记忆、文件、工作区、外部应用连接和智能体操作权限；网页层一旦获得同源代码执行能力，攻击面会随着产品能力同步扩张。

更值得警惕的是功能组合带来的“安全缝隙”。公开分享由内容团队负责，Preview 由代码执行团队负责，交互图表依赖 MathLive，CSP 由基础安全团队维护，每个模块单独测试都可能通过，但攻击者不会按组织架构寻找漏洞。

这类问题很难仅靠单元测试发现。厂商需要围绕真实用户路径进行组合式安全测试，例如让不可信 Preview 同时面对分享页、图表、附件、第三方组件和认证接口，检查低权限内容是否能影响更高权限的页面对象。

开发者应该吸取什么教训

**所有接收 postMessage 的页面都应把消息视为外部输入。**MDN 的文档明确强调，消息监听器必须核对发送者身份，否则可能形成跨站脚本攻击；对应文档的开源版本可以在 MDN GitHub 仓库 查看。

开发团队至少需要执行以下检查：

1. 同时验证 event.origin 与 event.source，不能只判断消息中的 type 字段。
2. 发送消息时避免使用宽泛的 * 作为 targetOrigin，优先指定精确来源。
3. 不允许跨窗口设置消息携带原始 HTML，尤其不能直接进入 innerHTML。
4. 对攻击者可影响的动态 iframe 强制添加 sandbox，并按最小权限开放能力。
5. 把 Trusted Types 当作写入控制，而不是输入清洗工具。
6. 把 CSP 当作纵深防御，而不是对不安全 DOM 路径的补丁。
7. 对分享页、预览器、富文本、附件和第三方组件进行跨功能攻击测试。

GitHub CodeQL 已将缺少来源验证的 postMessage 监听器归类为可自动检测的问题，开发者可在 CodeQL 查询文档 的相关安全规则中进一步排查类似模式。自动扫描不能证明消息逻辑完全安全，但非常适合发现那些没有任何 origin 检查的明显缺口。

普通用户现在需要做什么

**已经安装修复意味着用户不必因打开过普通分享链接而立即认定账户失守。**截至 2026 年 10 月 31 日，OpenAI 已确认相关前端拒绝这条攻击链使用的消息，研究团队披露的原始路径已无法按原方式复现。

如果用户在 10 月修复前打开过来源不明的 ChatGPT 分享链接，并同时发现陌生会话、异常设置、未知登录设备或数据泄露迹象，稳妥的处理方式仍然是退出所有设备、更新密码、启用多因素认证，并检查账户内连接的应用与工作区权限。

用户还应重新理解“官方域名链接”的风险。此次恶意载荷可以放在真正的 chatgpt.com/share/ 页面里，因此域名正确只能证明页面由 ChatGPT 托管，不能证明页面内的用户生成内容天然可信。随着 AI 平台允许用户分享应用、智能体、文件、代码和交互组件，官方域名正在变成一种内容平台，而不再等同于官方背书。

OpenAI Hub观点

**这是一条技术设计精巧、实际影响严重，却没有得到同等赏金回报的漏洞链。**它最值得关注的地方，不是 YouTube JSONP 或某一段具体实现，而是五个“各自没问题”的功能如何共同创造出账户接管能力。

ChatGPT 的基础 Preview 沙箱并没有被直接攻破，但沙箱旁边的特权组件愿意接受它的指令。这个结果提醒所有 AI 产品：安全隔离不能只检查容器本身，还要检查容器能向外发送什么、外部组件会相信什么，以及这些组件最终能创建哪些具有更高权限的对象。

下一阶段的 AI 安全竞争也不会只发生在模型对齐和提示词注入上。谁能把网页、Agent、连接器、文件、浏览器和第三方依赖之间的权限边界做得更清楚，谁才更有资格让用户把长期数据和真实操作权限交给 AI。

参考来源

• MathLive虚拟键盘代理源码：可查看跨 frame 消息类型、originValidator 与虚拟键盘通信机制。
• MathLive跨来源iframe问题：社区对虚拟键盘跨来源通信和目标来源配置的讨论。
• MathLive更新记录：包含不可信 HTML、JavaScript 注入与 DOM 清洗相关的安全修复记录。
• MDN的postMessage文档源码：说明消息接收方验证 origin 与 source 的必要性。
• OWASP XS-Leaks Cheat Sheet：整理跨窗口通信、来源校验及浏览器侧信道的防御建议。