ClaudeBleed：当浏览器智能体信任了错误的扩展

这是什么？

ClaudeBleed 是 LayerX Security 为 Claude in Chrome 浏览器扩展中一处信任边界漏洞所起的名字。LayerX 于 2026 年 4 月 27 日向 Anthropic 披露；Anthropic 于 2026 年 5 月 6 日发布扩展 1.0.70 版本，LayerX 在同一周公开了其分析。该缺陷使任意其他 Chrome 扩展——包括以零特殊权限安装的扩展——都能向 Claude 扩展发送命令并令其执行：读取活动标签页、代替用户浏览，以及触及 Gmail、Google Drive 和 GitHub 等已连接的资源。

这并非对模型的越狱。语言模型的行为完全符合设计预期。缺陷出在智能体周边的管道上：即扩展如何决定信任哪些消息。我们之所以报道它，是因为它清晰、新近且有公开文档地展示了一类故障——这类故障将在每一个驻留于浏览器的 AI 智能体中重现；同时也因为据报道首个补丁在数小时内即被绕过，这本身就是一条有用的教训。

工作原理

Chrome 扩展可以声明一个 externally_connectable 清单键。它列出了被允许向扩展后台 service worker 打开消息通道的 web 来源（origin，以及可选的其他扩展 ID）。这是一个合法机制——厂商自己的 web 应用正是借此与自己的扩展通信。

Claude 扩展允许来自在 claude.ai 来源下运行的脚本的消息，以便 Claude web 应用能与扩展协同。正如 LayerX 所述，缺陷在于消息处理器信任来源却从不验证发送方：

Design intent:   claude.ai web app  ──(trusted channel)──▶  Claude extension
Reality:         ANY script running in a claude.ai tab  ──▶  Claude extension
                 (including code injected by a second, unrelated extension)

任何扩展都能向用户访问的页面注入内容脚本（content script）。在已打开的 claude.ai 标签页中运行的内容脚本，是在 claude.ai 来源下执行的。由于处理器将信任决策建立在来源之上，而非建立在经过认证、经过验证的发送方身份之上，因此由扩展 B 植入的内容脚本，在扩展 A（Claude）看来与 Anthropic 自家的 web 应用毫无区别。于是扩展 B 可以发出与 Claude 自身界面相同的命令消息——而 Claude 会用用户已认证的会话去执行它们。

所报告的影响直接源自致命三要素：智能体拥有对私有数据的访问权（用户已登录的 Gmail、Drive、GitHub），它可被喂入不可信的指令（来自劫持它的扩展），并且它拥有外泄通道（它能浏览并发送）。把这些组合起来，一个毫无权限的扩展就能读取邮件、提取私有仓库内容并将数据带出——而不会触发那个本可提醒用户的权限请求。

此处不复现任何可用的攻击载荷。其机制——基于来源的信任而无发送方认证——正是全部要点，且早已公开。

不完整的首个补丁

1.0.70 版本并未移除 externally_connectable 处理器。据 LayerX 与 Business Standard 的报道，Anthropic 转而增加了一个审批流程，使以”标准”模式运行的扩展无法静默执行特权远程命令。LayerX 报告该层可被绕过：通过滥用侧边栏初始化流程，攻击者可创建一个不受新检查约束的**“特权”/“无需询问即执行”执行上下文**，从而恢复原有能力。Cybernews 报道补丁在发布后数小时内即被绕过。教训是架构层面的：在一个信任决策仍基于来源的处理器之上嫁接一个界面层审批提示，并不能关闭这道边界——只是增加了一个可绕过的步骤。

为何重要

驻留浏览器的智能体是一个快速增长的部署面，而它们恰好汇聚了攻击者想要的资产。一个已登录的浏览器是一个单一上下文，其中容纳着邮件、文件、源代码以及数十个服务的会话 cookie。一个能在该上下文中采取行动的智能体，从构造上看就是高价值目标。

有三点可以超越这一个扩展进行推广：

信任边界存在于扩展之间，而不仅是 web 页面与智能体之间。 大多数浏览器智能体的威胁模型都聚焦于智能体读取的页面内容（间接提示注入）。ClaudeBleed 提醒我们，共享同一标签页的相邻扩展同样属于威胁模型。externally_connectable 的来源检查是一种粗糙的工具：来源不等于身份。

权限请求不能替代正确的边界。 用户安装了 Claude 并授予了它访问权；用户并未有意识地授予某个第二扩展操控 Claude 的权利。当边界出错时，对一个组件给出的同意会静默地延伸到另一个组件。

“无需询问即执行”模式对安全是承重性的，而不仅是为了便利。 绕过路径恰恰经由一个特权的、无确认的执行路径。那些抑制确认提示的自治设置，正是在攻击者最需要去掉最后一道人工检查点时把它去掉了。

防御

面向浏览器 AI 智能体的用户与管理员：

1. 立即更新，然后持续关注。 确保 Claude in Chrome 处于最新版本（1.0.70 或更高）。由于首个补丁被报告为可绕过，请将”已修复”视为临时状态，并跟踪厂商后续的版本与公告，而非假定单次更新已关闭该问题。

2. 缩小扩展的影响半径。 该攻击需要在同一浏览器配置文件中存在第二个扩展。审查已安装的扩展，删除不再主动使用的，并优先为 AI 智能体工作使用一个仅包含智能体扩展的专用浏览器配置文件。共存的扩展越少，攻击面越小。

3. 关闭”无需询问即执行”/特权自治。 让智能体运行在确认最严格的模式。对任何读取私有数据或发起出站请求的操作，要求明确的人工批准。这正是绕过手法所要跳过的检查点。

4. 在企业中使用扩展白名单。 Chrome 企业策略（ExtensionInstallAllowlist / ExtensionInstallBlocklist）可强制阻止未受管理的扩展。若只允许安装经过审核的扩展，那么”任意扩展都能劫持它”的前提，对受管理的设备群基本就消失了。

5. 将敏感会话与智能体隔离开。 不要把智能体扩展放在你保持登录最敏感服务（金融、管理控制台、具有宽泛权限范围的代码托管）的同一配置文件中。分离的浏览器配置文件会形成扩展无法跨越的硬边界。

面向构建浏览器扩展或智能体的开发者：

6. 认证发送方，而不要信任来源。 externally_connectable 过滤的是哪些来源可以连接，但同一标签页中的所有脚本共享同一来源。如果你的处理器执行特权操作，请要求一个经过验证的按会话密钥，或一次注入内容脚本无法伪造的、经过密码学认证的握手——而不是仅仅检查 sender.origin。

7. 默认采用最小权限与显式确认。 特权执行模式应当失败即关闭：不应存在任何能逃逸审批流程的静默路径。将任何”无需询问即执行”模式视为安全相关功能，并对可进入该模式的路径进行威胁建模。

8. 对共存扩展进行威胁建模。 将”一个恶意的相邻扩展共享此标签页”纳入你的设计假设。在安装了一个刻意敌对的第二扩展的情况下进行测试。

状态

项目	来源	日期	备注
向 Anthropic 负责任披露	LayerX Security	2026-04-27	Claude in Chrome 中的信任边界缺陷
补丁发布——扩展 v1.0.70	Anthropic	2026-05-06	增加审批流程；保留 externally_connectable 处理器
公开分析”ClaudeBleed”	LayerX Security	2026-05-06	信任来源而不验证发送方
首个补丁被绕过的报道	Cybernews / Business Standard	~2026-05-11	特权”无需询问即执行”路径绕过了新检查

关键日期：披露于 2026-04-27，补丁于 2026-05-06，随后数日报道被绕过。最持久的视角是防御性的：浏览器中的 AI 智能体继承了其所处浏览器的信任边界，而来源检查不等于身份检查。无确认的特权自治，正是这道缺口转变为数据外泄之处——因此当下最廉价的缓解措施，就是关闭这种自治，并缩减与智能体共享配置文件的扩展集合。

---

本文为教育性与防御性内容。它描述了一处已公开披露、并由厂商修补的漏洞，且不复现任何可用的攻击载荷。行为与版本细节反映的是 2026 年 5 月底可获得的信息；请以厂商当前的公告为准核实。