你的 AI 助手,在听一个扩展的话

一条只被允许改动网页的浏览器扩展，拿到了 AI 助手的控制权。2026 年 9 月 16 日，安全研究机构 Forever Security 公开了这份研究，五款带 AI 助手的产品被同时点到了名。研究者给这套手法起了一个新名字，它既不是提示注入，也不是模型失控。多数人以为这类风险长在模型身上。这一次，护栏从头到尾没有被碰过。

问题不在模型，在那条从来没有设计过隔离的通道。

一、一条扩展，五款产品，9 月 16 日被摆上台面

研究的主作者是 Forever Security 的研究员 Gal Weizman。五款产品分别是 Opera 的 Neon、Google Chrome 里的 Gemini、Perplexity 的 Comet、Microsoft Edge 里的 Copilot，以及 Claude in Chrome。

五款产品里有一款要单说。Claude in Chrome 本身是一个 Chrome 扩展，研究方自己就把这句话写进了报告，它在整批发现里也是分量最轻的一条，因为那条路是扩展去打扩展。

Dark Reading 与 The Hacker News 都在 9 月 16 日报道了这件事。五家厂商都确认了各自的问题，也都支付了赏金。逐家赏金是 Google 7000 美元、Perplexity 7000 美元、Microsoft 5000 美元、Opera 900 美元、Anthropic 600 美元，相加 20,500 美元，约合 2 万美元。最高的两笔并列，Google 与 Perplexity 各 7000。

这起事件的关键坐标• 发现方是 Forever Security，研究员 Gal Weizman• 五款产品里，四款是浏览器，一款是浏览器扩展• 五家厂商都认了问题，也都付了赏金• 只有两家把事情推进到编号和补丁这一步

一条扩展的权限本来只够改网页。浏览器里的 AI 助手权限要高得多，它能看屏幕、开本地文件、调摄像头、替你在页面上点按。这两者之间有一道边界，这一次，扩展越过了它。扩展被设计成只能改网页，助手被设计成只听一个受信任页面，这两句话放在一起，那道边界就守不住了。

一条扩展的权限只够改网页，它改到的那张网页，正好管着助手。

二、AI 助手的身体在浏览器里，大脑在厂商服务器上

这类 AI 助手，并不是一个只在你浏览器里跑的聊天框。研究方把它拆成两半。一半是装在浏览器里的「身体」，能看屏幕上的内容、能打开本地文件、能调用摄像头与麦克风、能替你在页面上点按。另一半是跑在厂商服务器上的「大脑」，负责判断该做什么，再把动作指令发回来。

身体听谁的。它只接受一个受信任页面的指令。Chrome 里那个页面是 gemini.google.com，Opera Neon 里是 opera.com。这些页面由厂商提供，浏览器把它们当成可信来源。普通网页和普通扩展，本来都该碰不到它们。

研究方把这个结构写成了一句话。

Extensions can only change websites. But, what if an extension can mess with a website that controls your browser?（扩展只能改动网站。可要是扩展能动那个控制你浏览器的网站呢）

一条扩展要够到那个页面，需要两样常见权限。一样是往网页里注入脚本的内容脚本权限，广告拦截器就在用它来改写页面上的广告。另一样是改动浏览器网络请求的权限，学名叫 declarativeNetRequest，能拦下、改写、重定向浏览器发出的请求。

这两样权限单看都不算危险。改网页是扩展的本职，改网络请求也是它的常见用途。风险出现在两者组合起来，一起指向那个受信任页面的时候。

身体只听一个页面的话，而那个页面扩展改得动，助手于是开始听扩展的。

三、同一道门，五把不同的钥匙

五款产品的具体表现并不一样。有的要绕两层，有的只要一步。研究方的判断是，五款产品被利用的架构缺口只有一个。扩展越过了那道边界。那道边界本该把不受信任的扩展和高权限助手隔开，这一次没有被拦住。

Opera Neon 是门槛最低的一条。研究方发现，它的助手只听 opera.com 的话，而 Opera 没有拦住扩展在那个页面上运行代码。扩展把代码注进去，就能直接给助手发指令，再用网络请求的权限，让整个过程对用户完全不可见。

Chrome 那条要绕一层。浏览器拦住了扩展往 Gemini 页面注入脚本，却没有拦住扩展修改那条把 Gemini 加载进来的网络请求。研究者顺着这个缺口，让 Gemini 页面加载了他自己站点上的 JavaScript，因此拿到了浏览器里那个「身体」的控制权。拿到之后，他能截图、读本地文件、打开摄像头与麦克风，全程不需要用户点任何东西。

Comet 那条影响最大。Perplexity 把 Comet 做成一款全面由 AI 驱动的浏览器，助手权限给得最大。主站拦住了扩展，研究者就转向一个没有同样保护的测试域名 testing.perplexity.com。重定向的指令写在网络响应的头里，扩展拦下这个重定向，静默加载那个测试页，再往里注入代码。此后，它能读电脑上的任意文件，翻看用户访问过的所有网址，也能截图。

Edge 那条最费劲。微软建了一个带特殊权限、能向助手发提示的营销页。研究者先绕开保护这个页面的网络层防御，再借 Think 与 Do 两个模式之间的一个竞态条件，在正确的时机切换模式，让助手既收下指令，又去执行。

Claude in Chrome 那条最轻，因为它是扩展打扩展。研究方自己给出了最短的一句结论。

Claude in Chrome is a browser extension, not a browser.（Claude in Chrome 是一个浏览器扩展，不是浏览器）

这一句也带着一个限定。研究方称，Anthropic 认定他们是第一个报告 Claude in Chrome 这个问题的团队。更早还有公开的相关报告，安全公司 LayerX 在 4 月公开过 ClaudeBleed，Manifold Security 在 7 月报告过同类缺口在后续版本里仍然存在。带上这个前提，「第一个」才站得住。

研究方还整理了一张能力对照表，把本地文件读取、摄像头与麦克风、劫持助手、泄露浏览器配置、泄露用户历史、截图、零点击这几项逐款列了出来。零点击是五款全都具备的一项，攻击不需要用户点任何东西；劫持助手那一项，五款里有四款打了勾，Chrome 是唯一没有的，它走的是另一条路，控制的是浏览器里那个「身体」。剩下的能力集中度更高，能读本地文件、能截图的只有 Chrome 与 Comet，能翻用户访问历史的只有 Comet 一家。

五条路，门槛差在三处

一步就能拿下的两款• Opera Neon，助手只听 opera.com，而 Opera 没拦住扩展在那页上跑代码• Claude in Chrome，扩展打扩展，研究方自己把它列为最轻的一条

要绕一层到两层的三款• Chrome，脚本注入被拦住，网络请求那条没拦住• Comet，主站防住了，一个测试域名 testing.perplexity.com 没防住• Edge，要借一个营销页，再赌一次 Think 与 Do 之间的模式切换时机

Opera Neon 只要一步，Edge 要绕两层，最后被越过的都是扩展与助手之间那道边界。

四、这次攻击没有用提示注入，研究方给它起了个新名字

过去一年，讲到 AI 被攻击，主线多半是提示注入。做法是把指令藏在助手会读到的内容里，比如一篇文章、一封邮件、一段网页文字，然后指望助手把这段内容当成命令照做。这一类攻击盯的是模型会不会上当。

这一次的做法不同。研究方原话是这样一句。

we didn't even use prompt injection, because we discovered something worse（我们根本没有用提示注入，因为我们发现了更糟的东西）

攻击者没有把指令藏进任何内容里，他们把整条提示都写成自己的，一条接一条地发给助手，直到助手照做。研究方把这套手法命名为 Prompt-Forcing。这个名字说的是，提示由攻击者完整撰写、直接追发，不需要夹带在别的内容里送进来。

两者的对抗点不在同一处

提示注入｜过去一年的主线• 把指令藏进助手会读到的内容里，等它上钩• 对抗点在模型的判断力，问的是它会不会上当• 目标是被骗的那一次输出

Prompt-Forcing｜这一次• 整条提示由攻击者撰写，一条接一条追发到助手照做• 对抗点在通道，护栏和模型的判断力都没被碰过• 目标是从通道里持续下令

研究方还强调，这条路上没有恶意代码。传统的端点检测与响应系统（EDR）认的是代码特征，行为里没有可认的字节，它抓不到。Dark Reading 转述 Weizman 的说法是，攻击者不用把指令巧妙地藏进助手会读取的数据里再等它上钩，只要一条接一条地发，助手就会被说服去做任何事。

这一条把这次的事与「模型风险」分开。护栏从头到尾没有被碰，模型的判断力也没有被质疑。被利用的，是厂商把权限等级不同的扩展和助手放进同一条通道时，那道从来没有设计过的隔离。

研究方没有绕开任何护栏，他们只是把整条提示写成了自己的。

五、五家都承认了，两家给了编号

这说明研究方的结论不是自说自话。响应力度并不整齐，只有两家走到了编号和补丁这一步。

Chrome 那条的编号是 CVE-2026-0628，评分 8.8，由 CISA 评定，NIST 尚未发布评分。修复版本是 143.0.7499.192。研究方博客只说，这条研究在今年早些时候公开过，取名 GlicJack，博客没有给出月份，也没有给出修复版本号。2026 年 3 月公开、Chrome 143.0.7499.192 修复这两条，来自 The Hacker News 的转述。这份研究是把这条旧案与今年新增的四款放在一起讲，五款里只有 Chrome 一条不是本次首次出现。

Edge 那条的编号是 CVE-2026-55945。微软官方的定性是竞态条件导致的信息泄露，归类为 CWE-362，CVSS 3.1 评分为 4.2，修复版本是 150.0.4078.48。研究方更愿意把它描述成借竞态跨过信任边界，这是研究方自己的视角，与微软的官方措辞出处不同。

Comet、Opera Neon、Claude in Chrome 这三条没有 CVE，也没有公开的修复日期。这三家都付了赏金，但就研究描述的那个具体手法，没有给出修复日期。

五家的响应，分成两档

走到编号和补丁的两家• Google，CVE-2026-0628，8.8，CISA 评定，修复版本 143.0.7499.192• 微软，CVE-2026-55945，4.2，竞态导致的信息泄露，修复版本 150.0.4078.48

只付了赏金的三家• Perplexity 的 Comet，Opera 的 Neon，Anthropic 认定的 Claude in Chrome 那一条• 三条都没有 CVE，也没有公开的修复日期

这是研究者的演示，不是已经在发生的攻击。每一条路径都要求攻击者已经让受害者装好了那个扩展。截至 2026 年 9 月 16 日，两个 CVE 都没有进入 CISA 的已知被利用漏洞目录（KEV），也没有公开证据显示这五条路径被真实使用过。KEV 收录的是已经被实际利用的漏洞，没进去，本身就是一条有信息量的记录。

两家给到了 CVE 和版本号，三家只付了钱，截至 2026 年 9 月 16 日，两个编号都还没进已知被利用漏洞目录。

六、装了一堆扩展的浏览器，现在该检查什么

研究方给出的处置建议很具体。把组织里每一款 Chromium 系浏览器都更新到最新版本，把没审过、来源不明的扩展移除。Dark Reading 转述 Weizman 的话说，这类攻击绕过了当前的端点检测与响应系统，光靠端点上的特征匹配找不出来。

端点之外还有别的线索。Weizman 的建议是复盘过去和各个助手提供方服务器之间的交互，先定位可能受影响的端点。随后导出浏览器助手与其提供方服务器之间的会话记录，从里面找指向失陷的可疑行为。研究方进一步主张，应对这类智能体软件的威胁，要转到 AI 原生的端点方案上去。

研究方还主动把这件事和那个周末关于「过度强大的助手」的公开警告联系起来。原话大意是，这样过于强大的助手落到坏人手里，会有多危险。它说的是产品设计，不谈模型的性情。

现在能做的三件事• 更新，把在用的 Chromium 系浏览器都升到最新版本• 清理，去扩展列表里删掉认不出的、来源不明的、装完就没再用过的• 排查，企业侧可以导出助手与厂商服务器之间的会话记录，找可疑行为

对普通读者来说，眼下能做的动作很少，但很具体。用 Chrome 或 Edge 办公、又装了一堆扩展的人，先把浏览器更新到最新，再去扩展列表里，把认不出、装完就没再用过的那些清掉。企业里的安全团队，在更新和清理之外，还可以按 Weizman 的思路，去翻助手与厂商服务器之间的会话记录。

研究覆盖的是这五款 Chromium 系产品，而且前提是用户已经装了至少一个扩展。Firefox 与 Safari 不在名单之内。研究方估计这类产品的用户规模在数亿量级，这是 Weizman 的估计，不是审计出来的数字。

能做的事不多，把浏览器更新到最新，把认不出的扩展清掉，再去翻助手与厂商服务器之间的会话记录。

七、补丁已经发了，但那道边界还欠一次重新设计

版本号改掉了，两个 CVE 也发了。这次暴露出来的是一个设计问题。两个补丁各修各的那条路，问题本身还在。研究方的结论是，他们发现的所有漏洞共享同一个关键的设计缺陷。

研究方形容这个结构时说过，浏览器里坐着一个强大的助手，它听从某个自己信任得有点过头的东西。

缺口出在权限的粒度上。扩展的权限模型分不清「读一篇文章」和「读一段对话」这两件事。它只知道自己被允许改网页，不知道被改的那张网页背后，连着一个权限高得多的助手。扩展的权限模型比浏览器内置的 AI 助手出现得更早，这套模型当初也没有为网页背后坐着一个助手这种情形留出隔离。

只要助手继续住在浏览器里，继续和一个受信任页面共用同一条通道，这类缺口就会反复出现。研究方对扩展生态的判断也很直接，扩展危险性高，而针对它的监管与安全投入都接近为零。

需要补的那一步是重新画一次那条边界。把低权限扩展和高权限助手分开，让扩展碰不到那条通往助手的通道。已经发出来的补丁，每一个只堵住了自己那条路，改的是这条路怎么走。还没改的，是助手为什么会听那条路上送来的话。

补丁改了版本号，那道把低权限扩展和高权限助手分开的边界，还欠一次重新设计。

写在最后五个补丁会陆续到位，赏金也已经结清。往后同类的事还会再来，值得先确认的还是那一件。一条扩展要不要装，你点一下就知道结果；那条通往助手的通道有没有上锁，没有哪个界面会告诉你。咱们下期接着聊。

关注我「六一的 AI 人生记录仪」，一个做了快十年 AI 安全的老朋友。每周拆一个真案例，带你看清 AI 时代的安全账。记录 AI 时代的每天。

信源• Forever Security 研究博客，Gal Weizman，2026-09-16• Dark Reading 报道，Elizabeth Montalbano，2026-09-16• The Hacker News 报道，2026-09-16• NVD 与 CISA 关于 CVE-2026-0628 的评分• CVE.org 记录与微软 MSRC 关于 CVE-2026-55945 的公告