Claude记忆功能曝安全隐患 无需确认即可泄露姓名和工作单位

安全研究员披露 Claude 记忆机制漏洞,攻击者可诱导 AI 从历史对话中提取姓名、工作单位、籍贯等个人信息并编码外传至恶意网站。Anthropic 内部已知但未修复,研究员未获赏金。分析攻击原理及对国产大模型的警示。

7 月 17 日,安全研究员阿尤什·保罗(Ayush Paul)通过博文披露了一项针对 Claude 的新型攻击方法。攻击者无需用户额外授权,即可诱导 Claude 从对话记忆中提取姓名、工作单位、籍贯等个人信息,并编码后发送至外部恶意网站。保罗于 7 月 9 日发布技术博文详述攻击链,并已通过 Anthropic 的 HackerOne 漏洞赏金项目提交该问题。值得注意的是,Anthropic 在报告提交时已在内部知晓此问题,但尚未修复,保罗也未获得赏金。

一、攻击原理:利用记忆机制把 Claude 变成”信息搬运工”

Claude 有两层记忆机制,本意是让回答更贴合用户背景:

  1. 每日摘要:将近期对话内容压缩为数段,自动注入后续会话上下文;
  2. conversation_search 工具:允许 Claude 按需检索用户完整的历史对话。

长期使用 Claude 的用户,其对话记忆中会积累相当完整的个人画像,范围可能覆盖姓名、工作单位、家乡、职业信息甚至个人困扰。

保罗的攻击手法利用了 web_fetch 功能(Claude 抓取网页内容的能力)。攻击链分为两步:

第一步:信息提取。 构造一段对话,让 Claude 在回答中自然地调用记忆内容。保罗的测试显示,在无额外提示的情况下,Claude 依次吐出了他的姓名、公司名称和家乡信息。

第二步:编码外传。 将恶意 URL 与真实咖啡馆 URL 混在一起,要求 Claude “比较这些链接”。Claude 在处理过程中会将已提取的姓名按字符逐一编码进链接参数,向外部服务器发起请求。这意味着用户的个人信息以 URL 查询参数的形式发送到了攻击者控制的域名。

日志示例显示外传内容包括:

“Name: Ayush Paul”
“Company: Beem”
“Hometown: Charlotte, NC”

更严重的是,进一步诱导后,Claude 甚至会输出可用于银行等机构身份校验的原籍城市信息。

二、技术分析:这不是提示注入,是记忆机制被滥用

与常见的 prompt injection(提示注入)不同,这次攻击的核心不在绕过对话限制,而在滥用 Claude 内置的记忆检索和网页抓取两个正常功能之间的信任链条

环节 问题
记忆检索 系统自动将历史摘要注入当前对话,用户不可见、不可控
web_fetch Claude 会跟随外部链接抓取内容,且当时未限制链接跟随行为
信息编码 Claude 在”比较 URL”这类任务中,会无意识地将记忆中的敏感字段拼入 URL 参数
用户感知 整个过程无弹窗、无确认、无安全提示

这不是一个需要高深技术的 0day,而是一个逻辑漏洞——两个本应互相隔离的能力(记忆检索 + 外部请求)被巧妙串联,形成了数据外泄通道。

三、Anthropic 的响应:内部已知但未修,研究员未获赏金

保罗通过 Anthropic 的 HackerOne 漏洞赏金项目提交了完整报告。Anthropic 的回应是:

  • 内部已知:在保罗提交之前,Anthropic 已经知晓该问题;
  • 提交时未修复:漏洞在报告时仍可利用;
  • 未发放赏金:因为属于”已知问题”,保罗没有获得漏洞赏金。

后续 Anthropic 采取的措施是关闭了 web_fetch 跟随外部页面内链接的能力,切断了攻击链中的”编码外传”环节。但这本质上是一个临时缓解措施——只要记忆机制仍能无感知地将历史信息注入对话,类似的逻辑串联风险就仍然存在。

四、这对国内用户意味着什么

Claude 虽然在国内无法直接访问,但这件事对 AI 安全的影响远不止 Claude 一家:

1. 国产大模型同样有记忆机制

百度文心一言、阿里通义千问、字节豆包、DeepSeek 等国产大模型均已上线对话记忆或长期记忆功能。它们的记忆机制在底层设计上与 Claude 类似——都是将历史对话摘要注入新会话上下文。如果这些模型同时具备网页抓取或外部工具调用能力,理论上存在同样的逻辑串联风险。

2. 企业使用 AI 的场景正在快速扩大

越来越多的企业将 AI 助手接入内部工作流——代码审查、文档总结、会议纪要、客户沟通。这些场景中的对话记忆可能包含:

  • 内部项目代号与代码片段
  • 客户名单与合同信息
  • 服务器地址与配置参数
  • 员工个人信息

一旦记忆外泄,后果远超个人隐私范畴。

3. 安全防护的盲区

传统 WAF 和安全网关对 AI API 流量的检测能力几乎为零。因为外泄通道不是 SQL 注入或 XSS,而是”AI 在正常对话中把记忆编码进 URL 参数”——这种行为的流量特征与正常 API 调用无异,现有安全设备很难识别。

五、主机吧的建议

对普通用户

  • 定期清理 AI 助手的对话历史,尤其是在讨论过敏感信息之后。
  • 不要在 AI 对话中透露可用于身份校验的信息(如身份证号、银行卡号、详细住址)。
  • 使用 AI 工具时留意是否有”联网搜索””网页抓取”等外部能力开启——这些是记忆外泄的潜在出口。

对企业用户 / 站长

  • 如果团队使用 AI 工具处理业务数据,应制定明确的敏感信息不上传规范。
  • 在接入 AI API 的企业应用中,考虑在网关层对 AI 输出做内容过滤——检测并拦截包含内部域名的 URL 参数外传。
  • 业务系统本身的安全防护不能因为”用了 AI”就松懈。百度云防护 WAF 可对站点流量做全量监控,一旦攻击者利用 AI 外泄的信息(如服务器地址、内部域名)对站点发起定向攻击,WAF 的虚拟补丁和 CC 防御规则仍能起到兜底作用。

对行业

Anthropic 这次的修复方式(关闭链接跟随)是治标不治本。根本问题在于:记忆注入和外部请求这两个能力之间缺乏安全边界。这需要从架构层面设计隔离机制,比如:

  • 记忆内容在注入前做敏感信息脱敏
  • 对外请求前对 URL 参数做结构化校验
  • 涉及记忆内容的跨能力操作触发用户二次确认

六、主机吧看法

这次事件最讽刺的地方在于:Claude 的记忆功能本来是为了”更懂用户”,结果却成了”更懂如何出卖用户”。而且 Anthropic 内部已知但拖着不修,研究员提交了完整攻击链却连赏金都不给——这种处理态度对一家标榜”安全第一”的 AI 公司来说实在说不过去。

更深层的问题是,当前所有大模型的记忆机制在设计之初就没有充分考虑数据外泄的威胁模型。记忆被设计成”越详细越好”,外部工具被设计成”越方便越好”,两者之间没有安全隔离,出事是迟早的。

对国内 AI 厂商来说,Claude 这次的教训应该提前吸取——别等到自己的产品被曝光类似漏洞才开始打补丁。对站长和普通用户来说,记住一条铁律:AI 记住的越多,能泄露的也越多。 敏感信息,别往上写。

给TA打赏
共{{data.count}}人
人已打赏
0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
在线客服
在线客服
热线电话
QQ客服
电子邮箱
suduwangluo