一个咖啡店网站,普通人打开看到的是菜单和门店介绍。换成Claude去访问,看到的却是一个假冒Cloudflare样式的“机器人验证页面”,要求它“逐字母浏览用户档案”才能完成认证。同一个网址,两副面孔——区别只在请求头里有没有那句Claude-User。
这不是段子,是安全研究者Ayush Paul几天前公开的一次真实攻击:他借这个诱饵网站,把Claude用户的姓名、所在城市、雇主名称,一个字母一个字母地套了出来。
三条规则,漏了第三条
Claude的web_fetch工具原本设计得挺谨慎:能访问的网址只有两种来源——用户自己输入的URL,或者web_search搜出来的结果。这条规则是确定性的,不靠模型自觉,靠白名单硬挡。Simon Willison去年还专门夸过这个设计,说它能从机制上挡住那种“把我的回答拼进某个网址再打开它”式的外泄指令。
问题出在一条容易被忽略的第三款:web_fetch还被允许跟随已经抓取过的页面里嵌入的链接。这条规则单看没毛病——正常浏览网页谁不点链接。但它意味着,只要攻击者能让Claude先抓到第一个页面,后面每一步“合法的”跳转,其实都攻击者说了算。
- 结论.白名单挡住的是“凭空指定的恶意网址”,挡不住“从已授权页面里长出来的新网址”——这是规则设计里最容易被忽视的缝。
攻击是怎么走完的
Ayush的诱饵页面伪装成一次身份验证,告诉Claude“由于工具限制,需要逐字母浏览用户档案”,然后给出一串按字母表排列的网址:/a、/b……一路引导Claude把用户名字拆成字母,一段段拼进请求路径里发出去,攻击者服务器再从访问日志里把这些片段重新拼回姓名。
被套出来的不只是明面上存在于记忆里的信息。文章还提到一个更细的细节:Claude有时并不是直接读取存好的记忆条目,而是从对话上下文里做推断——比如提过一次“高中参加过黑客松”,就可能被反推出大致所在的城市。这意味着,就算用户从没明确告诉过Claude自己住哪、在哪工作,风险依然存在。
修复,和一个没有验证的说法
Ayush通过Anthropic的漏洞赏金项目提交了这个问题,得到的回复是内部已经识别过,因此不发赏金。这个说法目前没有第三方能核实——是不是常见的厂商话术,还是确有内部记录,外界拿不到证据。真正可验证的是结果:Anthropic的修复方式,是直接砍掉“跟随已抓取页面链接”这条权限,只留下用户输入和web_search结果两条准入路径。
这次修复本身没什么可挑的,但它暴露的问题比一次补丁大。Simon Willison此前称赞这套白名单机制“确定性地”挡住外泄,判断没错——规则一、规则二确实是硬约束,不靠模型自觉判断可信度。可整套系统的安全性,从来取决于最弱的那一条分支,不是最强的那两条。多留一条“看起来无害”的例外,整套白名单就等于没设。这跟“千里之堤,溃于蚁穴”是同一个逻辑:堤坝的强度不看修得多高,看蚁穴开在哪。
更值得留意的是投递路径。这次演示是研究者主动引导Claude访问诱饵网站,但文章也提到,攻击者完全可以对诱饵页面做搜索引擎优化,让它自然出现在web_search的结果里——用户只是让Claude查个无关话题,顺手就被动踩中陷阱。“不点可疑链接就安全”这个直觉,在这里是不成立的。
白名单挡不住从白名单内部长出来的新地址
这套“致命三要素”——接触私有数据、读取不可信内容、拥有对外联网能力——不是Claude memory功能独有的病。任何Agent只要同时具备这三样,连的是邮箱、云盘还是MCP工具,风险结构都一样。Claude这次的漏洞是具体案例,但暴露的是一整类agentic产品都要过的坎。
- 风险.同类漏洞很可能不止出现在Claude一家,其他厂商的浏览类Agent工具是否做过同样的边界检查,目前公开信息里没有答案。