夜雨聆风一个装了Claude浏览器扩展的上班族，某天发现自己的Gmail被悄然翻了个底朝天——而发号施令的，根本不是他自己。
一、AI越聪明，边界越模糊
大语言模型正在以惊人的速度接管我们的浏览器。读邮件、写文档、安排日程、操作CRM——这些原本需要用户亲手完成的事，如今只需一句"帮我把今天的邮件整理一下"，Claude就会替你搞定。
但当AI被赋予越来越高的操作权限时，一个根本性问题却常常被忽视：谁在为AI下达指令？
Manifold Security最新披露的研究揭示了一个令人不安的事实：Anthropic旗下Claude for Chrome扩展当前版本（v1.0.80）中存在两处尚未修复的安全缺陷，能够让第三方在未经许可的情况下直接操纵Claude执行敏感操作。这并非理论上的风险，而是已经被验证、只需6行JavaScript即可触发的实际攻击。
二、六行代码，一键接管你的数字生活
第一个问题的根源，藏在扩展处理用户点击事件的方式里。
为了应对今年5月初LayerX披露的"ClaudeBleed"漏洞，Anthropic在扩展中加入了一个"白名单"机制：页面不再能向Claude发送任意文本，而只能从9个预设任务ID中选择一个触发。这9个任务包括读取Gmail、打开Google Docs、扫描Calendar、操作Salesforce等——覆盖了一个职场人日常数字工作的核心场景。
这看起来是道扎实的防线，直到有人注意到一个细节：触发这9个任务的点击处理程序，没有验证事件是否来自真实用户。
在浏览器安全模型中，event.isTrusted 是区分"真人点击"与"脚本伪造点击"的关键标志。正常情况下，任何涉及敏感操作的交互都应该检查这一属性。但Claude扩展的点击监听器直接跳过了这一步——这意味着任何能够在 claude.ai 域下执行脚本的浏览器扩展，都可以凭空构造一个按钮、设置一个任务ID、触发一次合成点击，让Claude乖乖执行预设操作。
攻击代码只需要6行。从DevTools控制台粘贴、回车，你的AI助手就开始替攻击者工作了。
在默认模式下，Claude还会弹出一个审批窗口，用户至少还有一次叫停的机会。但如果用户曾经开启过"Act without asking"（无需询问直接执行）模式——这也是很多追求效率的用户会选择的功能——整个攻击链将完全静默，没有任何可见提示。没有弹窗，没有确认，Claude直接访问你的Gmail、读取最新的文档批注、翻看日历安排，仿佛一切正常。
这个差距在CVSS评分中体现得淋漓尽致：默认模式下7.7分（高危），开启自动执行后飙升至9.6分（严重）。
三、URL里的"特权开关"
第二个问题藏在扩展的架构设计里。
Claude的侧面板在加载时，会读取自身URL中的 skipPermissions=true 参数。一旦检测到该参数，面板直接进入"跳过所有权限检查"的特权模式，不需要任何用户手势、不需要任何明确授权。虽然扩展会在面板顶部显示一条"高风险"提示横幅，但这条横幅出现在特权模式已经建立之后——它不是一道门，而是一张事后通知。
目前这个攻击面还无法被远程直接利用，因为构造侧面板URL仍然需要扩展级别的权限。但这枚"定时炸弹"的危险之处在于：它与任何URL构造漏洞的组合都是致命的。
想象一下：如果未来某个版本中出现一个新的消息处理器错误地接受外部传入的URL字符串，或者某个配置页面出现了XSS漏洞，又或者某次代码回归重新允许发送者指定权限模式——攻击者将立即获得一条静默通往完全特权的捷径。不需要伪造点击，不需要绕过白名单，只需要一个被污染的URL参数。
这两个漏洞叠加在一起，构成了一条完整的攻击链：伪造点击触发任务 -> 侧面板已进入特权模式 -> 敏感操作静默执行。这也是研究者将第二个问题定性为"结构性风险"的核心原因。
四、八次更新，代码纹丝未动
Manifold Security在5月21日向Anthropic报告了这两个问题。对方次日确认了报告，随后关闭了工单——理由是合成点击问题已被内部跟踪，URL参数问题则被视为"无可达攻击路径"。
此后，Anthropic密集发布了v1.0.73到v1.0.80共八个版本。研究者逐一验证后发现：相关代码与最初测试的v1.0.72版本字节级一致，完全没有改动。
这种"宣布修复、实则未动"的模式并非首次出现。回顾今年5月的ClaudeBleed事件——Anthropic曾发布补丁称已限制标准模式扩展的远程命令执行能力，但研究人员在数小时内就找到了绕过方式。历史似乎在重复。
更值得警惕的是，这类攻击在现有安全监控体系下几乎是隐形的。网络网关看到的是通往 claude.ai 的正常HTTPS流量，EDR看到的是浏览器扩展的正常运行，日志里没有任何异常。AI代理调用了它本不该被触发的工具，而唯一的信号出现在运行时——不是授权层说了什么，而是AI实际做了什么。
五、信任边界：AI产品安全的阿喀琉斯之踵
这两个漏洞在OWASP LLM应用安全风险Top 10中有明确对应：LLM01（提示注入，间接类型）和LLM06（过度代理）。
它们暴露了一个深层的设计困境。Claude扩展在"消息处理器层"做了正确的事——引入白名单，限制外部能发送的指令范围；但在"事件意图层"掉了链子——没有确保触发白名单的是真实用户意愿。两层之间缺少了一道关键检查，使得上层的安全机制形同虚设。
这不是Anthropic独有的问题。从Microsoft Semantic Kernel的RCE漏洞，到ChatGPT的ChatGPhish攻击链，再到各类AI代理的权限绕过——"信任边界在A层守住了，却在B层失守"正在成为AI产品安全的典型失败模式。
传统软件的安全模型建立在"用户明确授权"的基础上。但在AI代理的世界里，授权链条被大大延伸了：用户授权AI -> AI授权工具 -> 工具授权操作。每一层延伸都意味着信任边界的重新划定，而每一次重新划定都可能引入新的断裂点。
六、用户该怎么办
在官方彻底修复之前，如果你正在使用Claude for Chrome，建议采取以下措施：
- 关闭"Act without asking"模式：这是阻断静默攻击最有效的手段。虽然无法阻止恶意扩展触发Claude，但至少每次敏感操作都需要你手动确认。
- 审视已安装的浏览器扩展：任何声明了
claude.ai内容脚本权限的扩展都处于攻击路径上。只保留你真正信任且必需的扩展。 - 企业用户考虑管控策略：通过Chrome Enterprise Policy限制Claude扩展的运行，或为其配置更严格的权限范围，直到厂商发布经验证的完整补丁。
- 关注运行时行为：传统的网络监控和EDR对这类攻击几乎无能为力。如果你所在的企业正在大规模部署AI浏览器代理，考虑引入专门针对AI代理运行时行为的监控能力——看AI实际做了什么，而不是授权层声称它能做什么。
AI正在以前所未有的深度嵌入我们的数字工作流。但当AI的"代理权"越来越大时，确保它只听从真正的主人——而不是任何一个能伪造6行JavaScript的陌生人——这是整个行业都需要正视的问题。在厂商补上这一课之前，用户和企业的谨慎或许是最可靠的防线。
七、参考来源
- https://www.manifold.security/blog/claude-for-chrome-extension-bypass
- https://thehackernews.com/2026/07/claude-for-chrome-flaw-lets-other.html