当智能体的"身体"被劫持——一个扩展就能驱动五款产品的 AI 助手

2026 年 9 月，Forever Security 研究员 Gal Weizman 证明，仅持有两个常见权限（页面修改与 declarativeNetRequest）的一个浏览器扩展，即可控制五款产品的内置 AI 助手：Chrome 中的 Gemini Live、Perplexity Comet、Microsoft Edge、Opera Neon 以及 Claude in Chrome 扩展。各产品的架构相同：AI 在浏览器内有一个能看屏幕、打开文件、使用摄像头的"身体"，以及一个位于厂商服务器上的"大脑"，而这个身体只接受来自单一受信任页面（如 gemini.google.com）的指令。扩展把自己的代码滑入该受信任页面，冒充厂商向身体发号施令。Chrome 的案例即众所周知的 GlicJack，对应 CVE-2026-0628（CVSS 8.8，已在 Chrome 143 修复）；只有 Edge 的发现也获得了 CVE，即 CVE-2026-55945（CVSS 4.2，已修复）。Comet、Opera Neon 和 Claude 没有 CVE。Comet 是最糟的情况——被劫持后，其智能体可读取任意文件、列出浏览历史、截屏并代替用户操作。所有发现均为研究员演示，并非在野攻击，且都以扩展已安装在受害者一侧为前提（据 The Hacker News 报道）。

在另一条线索中，Mandiant 的 2026 年 9 月报告描述了某匿名 SaaS 服务商处攻击者劫持一个进行中的 AI 编码助手会话的案例。劫持之后，该助手针对攻击者预先投毒的软件给出的"推荐"被人类接受，攻击者借开发者的会话，通过公司官方命名空间内一个被投毒的 PyPI 包安装了信息窃取器（infostealer）。GitHub OAuth 令牌被窃取，自我复制的 Shai-Hulud 蠕虫被部署到约 100 个内部仓库；另一名员工拉取了被投毒的版本造成二次感染。Mandiant 此前还报告称，攻击者在 2025 年间已从"用生成式 AI 加速工作"阶段转入"在恶意软件和实时攻击中嵌入 LLM"阶段（据 The Hacker News 与 Mandiant 报道）。

分析（与事实分开）：两个事件的共同点在于，智能体架构的信任边界建立在"页面"和"推荐"之上，而非"人类的审批"。browser use 型智能体只认单一受信任域名作为指令来源——但扩展可以改写该页面的内容，于是扩展就成了通往信任边界的供给路径。在编码智能体一侧，人类对 AI 推荐的"批准"本身就是执行权限的授予：如果推荐方的输入（包注册表）被污染，批准就成了攻击的触发器。Human-in-the-loop 通常被当作安全措施来谈论，但在这两个案例中，回路里的人类都没有验证推荐内容——批准仅停留于形式。

防御侧启示：(1) 在启用了 AI 助手的终端上，应将扩展权限盘点与智能体能力盘点一并进行——如果一个扩展能通过智能体的"身体"触达文件读取和摄像头调用，那么授予它权限实质上就是授予权限。(2) 凡是 AI 推荐的包或工具，即使有人类批准，也应视为新开辟的供给路径并纳入验证对象。(3) 受信任域名一侧要盘点诸如测试子域名之类的"被遗忘的命令通道"（在 Comet 案例中，一个遗留的 testing 地址正是突破口）。(4) 最小化智能体可读的文件及其持有的令牌（如 OAuth）。以上均为本文分析，并非厂商官方观点。

本文的事实依据以 Forever Security 的 BragJack 报告（https://forever.security/blog/bragjack-hijacking-5-browsers-via-built-in-ai-assistants/）以及 Mandiant / Google Cloud 的 AI Risk and Resilience Report 2026（https://cloud.google.com/security/resources/ai-risk-and-resilience-2026）为一次来源，以 The Hacker News 的报道（https://thehackernews.com/2026/09/one-extension-could-hijack-ai.html 与 https://thehackernews.com/2026/09/attacker-hijacks-ai-coding-assistant.html）为二次来源；分析部分已与事实报道分开记述。另请留意，对于未获 CVE 编号的产品，厂商的修复状况无法从公开信息完全确认。