一个Chrome扩展的通配符配置错误，让300万用户的浏览器成了黑客的提线木偶。KOI安全团队发现的这个漏洞链，全程不需要用户点任何按钮。
零点击攻击的完整链路：从通配符到全权限接管
Claude浏览器扩展的设计初衷是帮用户自动操作网页——填表、搜索、整理信息。这个"自主代理"能力在攻击者手里，变成了批量窃取数据的完美工具。
漏洞的核心藏在扩展的消息验证机制里。扩展用*.claude.ai作为白名单，匹配所有子域名。这个通配符看起来合理，直到你意识到它把a-cdn.claude.ai也包了进去——这是Anthropic用来托管Arkose Labs验证码组件的CDN域名。
Arkose的某个旧版本组件存在DOM型XSS漏洞：它接收任意父页面的postMessage消息时不验证来源，还把用户传入的stringTable字段直接塞进dangerouslySetInnerHTML。React的这个API名字已经警告过开发者了，但显然没拦住历史遗留代码。
攻击者只需要在恶意页面里藏一个不可见的iframe，加载那个有漏洞的旧版验证码组件。用户打开页面的瞬间，iframe里的脚本注入执行，向Claude扩展发送onboarding_task消息。扩展一看来源是*.claude.ai，直接放行。Claude收到"用户指令"，开始执行攻击者预设的操作。
整个过程没有弹窗、没有授权提示、没有任何视觉反馈。用户可能只是在某个论坛看了个帖子，Gmail的OAuth令牌就已经被发往黑客服务器了。
攻击者能做什么：比你想的更脏
KOI团队复现的攻击场景包括：窃取持久的Google OAuth访问令牌、读取Gmail内容、导出Google Drive文件、批量发送钓鱼邮件。因为Claude扩展本身有页面导航和JavaScript执行能力，攻击者甚至可以让你"自己"去访问更多恶意页面，扩大感染面。
最讽刺的是，这个漏洞利用了Claude最引以为傲的功能——自主浏览器代理。Anthropic花了大力气让AI能替用户操作网页，结果这个能力被原封不动地借给了攻击者。你教AI帮你干活，黑客教AI帮你泄密。
漏洞披露时间线是：2025年12月26日通过HackerOne提交，Anthropic确认后修复。从披露到补丁的具体间隔原文未提及，但"now patched"的表述说明修复已完成。
第三方组件的信任陷阱
这个案例的教训在于供应链安全的连锁反应。Anthropic自己的代码只错了一步——通配符太宽——但这一步让第三方组件的旧版本漏洞有了用武之地。Arkose的CDN还保留着可预测路径的历史版本，给暴力枚举留下了空间。
浏览器扩展的权限模型在这里也暴露了设计缺陷。一旦扩展被授予"读取和更改所有网站数据"的权限，它就相当于用户浏览器里的root账户。而大多数用户在安装时根本不会细看权限列表，点了"添加扩展"就完事。
Claude扩展的onboarding_task消息类型设计尤其值得商榷。它直接把外部传入的prompt参数转发给Claude执行，中间没有额外的用户确认层。这种"便利优先"的设计哲学，在AI代理场景下正在被反复惩罚。
类似的漏洞模式其实不新鲜。2024年Google的Gemini扩展也曾因postMessage处理不当被曝出风险，当时的问题同样是来源验证缺失。浏览器扩展作为AI能力的延伸接口，正在成为攻击者的新靶场。
修复之后：用户该做什么
如果你安装过Claude Chrome扩展，检查版本更新记录是必要的。虽然漏洞已修复，但攻击是否被实际利用过——原文未提及Anthropic是否发现了野外利用证据——这个信息目前缺失。
更深层的问题是，这类"AI代理"扩展的安全模型是否可持续。每次用户让Claude"帮我总结一下这封邮件"，本质上都是在授予AI临时的高权限访问。当这个授权链条可以被第三方网页无声劫持时，便利和安全的平衡就彻底崩了。
Anthropic的回应原文未完整引用，但"responsibly disclosed"和"now patched"的表述表明漏洞处理流程走完了标准路径。对于一家以AI安全研究著称的公司来说，这个漏洞的戏剧性在于：它攻击的正是AI系统最脆弱的环节——不是模型本身，而是模型与外部世界交互的接口。
浏览器扩展的代码审计通常不如主产品严格，这个案例可能会推动更多AI公司重新审视它们的边缘组件。毕竟，用户不会因为"这只是个扩展"就原谅你的数据泄露。
最后留个思考题：当你的AI助手能自动登录银行、发邮件、改密码时，你怎么知道下指令的是你自己，还是某个藏在iframe里的陌生人？
热门跟贴