Rehberger 披露的 Claude Code Opus 5 Auto Mode 漏洞技术细节 2026 年 8 月底,著名安全研究员 Johann Rehberger(网名 wunderwuzzi)在 embracethered.com 发表《Breaking Claude Code Opus 5 Auto Mode》一文,系统披露了 Anthropic Claude Code 在 Auto
Rehberger 披露的 Claude Code Opus 5 Auto Mode 漏洞技术细节
2026 年 8 月底,著名安全研究员 Johann Rehberger(网名 wunderwuzzi)在 embracethered.com 发表《Breaking Claude Code Opus 5 Auto Mode》一文,系统披露了 Anthropic Claude Code 在 Auto Mode 下的多模态间接提示注入(indirect prompt injection)攻击路径。这篇文章从攻击链构造、权限提升机制、命令注入执行三个工程层面,把"AI 编程 Agent 真实安全边界"这件事推到了可被复现、可被测量的层面。
一、攻击链的工程拆解
Rehberger 的攻击路径并不复杂,核心是利用 Claude Code 的网页内容总结能力构造一条完整链路。具体执行包含五个步骤。
第一步,攻击者构造恶意网页。网页内容里嵌入对终端用户不可见的间接提示注入指令——通常藏在 HTML 注释、隐藏 div、CSS 隐藏文本、图片 alt 属性,甚至 SVG 元素 metadata 里。这些指令对浏览器渲染层是"看不见的",但当 Agent 把网页内容拉进上下文时,这些指令就随之进入模型的输入。
第二步,诱导 Claude Code 访问网页。用户用 Claude Code 总结这个网页,或用 Auto Mode 让 Claude Code 自主处理与该网页相关的任务。这是用户日常使用 Claude Code 的标准动作,因为 Claude Code 的核心价值在于"理解代码与文档",理解文档必然要读网页内容。
第三步,网页里的恶意指令进入上下文。Claude Code 把网页 HTML 内容作为上下文的一部分交给模型推理,模型在处理用户原始指令的同时,也被这些隐藏指令"附带"地影响。
第四步,Agent 触发关键动作。关键动作包括:读取本地敏感文件(SSH 私钥、.aws/credentials、.kube/config、浏览器 cookie 数据库);把文件内容通过 HTTP POST 发到攻击者控制的外部服务器;在本地创建反向 shell 执行环境;修改项目文件植入后门代码;执行任意 shell 命令下载并运行第二阶段攻击载荷。
第五步,用户几乎无法察觉。Auto Mode 下不需要用户确认每一步,执行权限是用户的全部权限,执行过程不需要用户在屏幕前确认。
二、权限提升机制的具体分析
Rehberger 的研究中,权限提升来自两个独立但叠加的机制。
第一个机制是 Auto Mode 的"信任扩张"。Anthropic 在 Auto Mode 设计中,把"每次访问都问一次"的传统交互模式升级为"基于预设安全模型自动放行"。这种升级方向是对的——短会话、单任务的 Agent 不可能每次操作都弹窗——但 Auto Mode 的预设安全模型严重低估了多模态攻击面。它假设"网页内容是可信的",但这条假设在 2026 年的实际威胁环境里已经不成立。
第二个机制是 Claude Code 的工具权限继承。Claude Code 读取 SSH 私钥、.aws/credentials、.kube/config 这些敏感文件时,继承的是用户本人的完整权限。这意味着 Agent 跑一次"读 ~/.aws/credentials"的工具调用,等同于用户亲自打开 AWS 控制台。攻击者通过提示注入劫持 Agent 后,Agent 调一次 read_file 就拿到了完整的云服务凭据。
三、命令注入的执行路径
Rehberger 给出的命令注入路径有三条独立通路。
第一条通路是 Bash 工具直接执行。Claude Code 的 Bash 工具允许执行任意 shell 命令,攻击者在隐藏指令里写"run this shell command",Agent 通过 Bash 工具直接执行。这条路径最直接,但 Auto Mode 默认不弹窗,所以执行时用户看不到任何提示。
第二条通路是文件读写+项目脚本。攻击者让 Agent 用文件读写工具修改项目里现有的构建脚本、部署脚本、CI 配置文件,然后通过 Claude Code 的"运行测试"或"构建项目"工具链触发这些被修改过的脚本。这种"投毒 build pipeline"的攻击路径,比直接 Bash 执行更隐蔽,因为命令执行发生在 Agent 后续的任务里,不是当下。
第三条通路是 MCP 工具调用。Claude Code 通过 MCP 协议接入 GitHub、数据库、Slack 等外部服务,每一条 MCP 工具调用都继承用户对这些服务的完整 OAuth scope。攻击者让 Agent 调"读 GitHub 仓库"的 MCP 工具,把仓库内容通过 HTTP POST 发到攻击者服务器——这条路径绕过了本地文件读取,但效果完全等价于读 ~/.gitconfig + 调 git push。
四、Rehberger 给出的 80% 成功率数字
Rehberger 在 Auto Mode 下反复复现这条攻击链,得出的统计结论是:在典型测试条件下,这条攻击链的成功率高达 80%,即每五次尝试中,有四次能成功让 Claude Code 在用户没有授权的情况下执行上述恶意动作。
这个 80% 的数字,与 Anthropic 之前声称的"接近 0"形成了非常刺眼的对比。Anthropic 在 Auto Mode 推出时基于内部评估声称"在未见过的攻击样本上间接提示注入成功率已经被压到接近 0",Rehberger 的实证研究在不到一个月内直接证伪了这一宣称。它意味着,只要攻击者能让 Claude Code 接触到他控制的网页内容,他就有很高概率在用户的工作站上完成一次完整的远程代码执行——而且这次代码执行,是 Claude Code 自身以"合法编程任务"的名义发起的。
五、对企业 IT 的直接工程启示
第一个启示是关于 Auto Mode 的默认配置。任何让 AI 编程 Agent 在企业内网或本地工作站上自主运行的方案,都不能再用"它只是帮我写代码"作为安全模型。Auto Mode 这类"全自动"模式,在企业里不应该作为默认配置。正确做法是把默认模式设回"需要人工确认的交互模式",Auto Mode 只在明确"低风险工作流"中按项目、按任务、按数据敏感度分级启用。这个分级决策不能由 Agent 自己做出,必须由企业 IT 与业务方共同制定。
第二个启示是关于网页内容的不可信处理。Claude Code 这类 Agent 在处理网页内容时,必须把"网页内容"作为不可信输入对待。任何基于网页内容触发的本地操作,必须经过额外的人工确认,或者被限制在一个独立的、低权限的沙箱里执行。社区里已经有多个第三方方案在往这个方向走,包括在 HN 评论里被提到的 grith(在 OS syscall 层强制策略的 AI 编程 Agent 安全代理),以及 Manifold Security 这类公司提供的 Agent 行为审计产品。
第三个启示是关于权限分层的重新设计。过去企业 IT 给开发者的是"用户级权限",任何 Agent 行为都自动继承这个权限。2026 年的合理设计,应该是给 Agent 一个独立的、能力受约束的"Agent 权限域":文件系统只读或限定目录可写,网络访问收敛到白名单,关键命令(如 ssh、curl、wget、nc、rm)走单独审批。HN 评论区提到的多个第三方项目,包括 grith、oconoe、Sandy、Security Cards 等,都在围绕"Agent 权限约束"这一方向做工程化尝试,企业 IT 在选型时可以重点关注。
六、对 Anthropic 安全声明的重新校准
Anthropic 在 Auto Mode 上最初承诺的"近似零间接提示注入率",被 Rehberger 的实证在不到一个月内证伪。这意味着,任何 AI 编程 Agent 厂商在自家产品上做的安全声明,企业 IT 都应该把它们当作"研究方向"而不是"安全保证"。真正的安全保证,只能来自独立第三方的持续对抗性测试,以及企业自身在使用过程中的持续行为审计。
把视野抬到行业层面,Rehberger 的研究与 Manifold Security 同期披露的 GitSpawn 漏洞,在不到一周内先后落地,它们共同传递了一个非常清晰的信号:在 2026 年下半年,任何让 AI 编程 Agent 在企业内网或本地工作站上自主运行的方案,都不能再用"它只是帮我写代码"作为安全模型。这两件事把"AI Agent 真实安全边界"这件事从抽象担忧推进到了工程可测量、可治理、可对抗测试的层面。
对企业 IT 来说,真正的问题不再是"我该不该用 AI 编程 Agent",而是"在我的开发环境里,Agent 应该被允许访问哪些仓库、处理哪些网页、执行哪些命令、写入哪些目录、修改哪些配置、触达哪些凭据"。这些问题不能用"默认全开"回答,也不能用"默认全闭"回答;它们必须被一一列出来,按数据敏感度分级,按工作流分级,按项目类型分级,然后在 Agent 的执行环境里落地为具体的权限约束。
