Anthropic 委托第三方评测机构 Trajectory Labs 完成的 72 项基准测试中，Claude Code Opus 5 在 Auto Mode（自动化模式）下的间接提示词注入攻击成功率为 0.00%。但在安全研究员 Johann Rehberger 于 2026 年 8 月 27 日公开的实战漏洞报告中，攻击者仅通过一条看似无害的“总结网站内容”常规指令，就让 Claude Code 在 Auto Mode 下触发了完整的远程代码执行（RCE），实测攻击成功率达到 60% 至 80%。
表面看这是 AI 意图分类器被巧妙绕过，本质上是把概率模型决策当作确定性安全边界的系统级缺陷。当编码智能体在本地操作系统上获得免确认的工具执行权，任何缺乏物理沙箱隔离的运行环境，都会在复合型攻击链面前彻底沦陷。
五步诱导链拆解，智能体在自主纠错中触发模块遮蔽
本次披露的攻击手法没有直接向大模型输入恶意提示词，而是通过操控环境反馈，让恶意路径变成 AI 眼中达成目标的唯一合理选项。
[步骤 1: 415 错误] -> Claude 自主改用 curl 抓取
[步骤 2: 303 重定向] -> 下载包含伪装文件的 ZIP 压缩包
[步骤 3: 拒绝二进制] -> Claude 决定自写 Python 解码脚本
[步骤 4: 模块遮蔽] -> import base64 触发同目录恶意 struct.py
[步骤 5: 隔离子进程] -> 建立 C2 回调或生成第二层无头 Agent
第一步是网络工具降级。攻击者服务器在接收到 Claude Code 的 WebFetch 工具请求时，主动返回 415 Unsupported Media Type 错误。Claude 面对工具报错，会自主决定改用系统底层的 curl 命令直接抓取目标网页。
第二步是文件重定向投毒。服务器通过 303 重定向返回一个 ZIP 压缩包，解压后包含数据清单、编码笔记本、一个名为 decoder-darwin 的二进制可执行文件，以及一个名为 struct.py 的脚本。
第三步是诱导自主编码。Claude 在审查文件列表时表现出了预设的防御倾向，主动拒绝运行未知的二进制文件 decoder-darwin。为了继续完成用户的总结任务，Claude 决定在解压目录内自行编写一段 Python 解码脚本。
第四步是模块遮蔽（Module Shadowing，指当前工作目录下的自定义脚本文件名与 Python 标准库重名，导致解释器优先加载当前目录脚本）。Claude 编写的脚本中包含 import base64，而 Python 标准库的 base64 内部依赖了 struct 模块。当脚本在解压目录直接运行时，系统优先加载了解压包内的恶意 struct.py。该恶意模块在重新导出底层真实接口以维持程序正常运行的同时，在导入阶段执行了混淆的恶意表达式。
第五步是建立驻留与反弹。恶意 struct.py 启动了一个独立的子进程（python3 -I -c），下载远程原生载荷建立 C2（命令控制通道）回调，并在本地弹出计算器验证权限。在拓展变体测试中，恶意脚本甚至能通过 claude -p 启动第二个无头的 Claude Code 实例，让子智能体利用自身的工具权限在后台执行主机侦察与文件写入。
分类器的判定断层，安全防护机制反向阻止清理操作
Auto Mode 的核心防御机制是意图分类器（Intent Classifier，一种用于在后台快速判断命令是否具有破坏性的轻量模型），用来替代频繁打扰开发者的人工审批弹窗。但实测证明，分类器与复杂攻击链之间存在明显断层。
在多次测试中，直接反弹 C2 链的成功率为 3/5（60%），启动无头子进程并写入文件的成功率则达到 4/5（80%）。这一结果与官方基准测试的 0.00% 并不矛盾。官方评测基于预设的 72 个固定测试集，主要针对直接注入指令；而实战攻击利用的是运行环境中的多步骤交互，AI 走的每一步在分类器眼中都符合正常编程逻辑。
更严峻的问题发生在攻击触发之后。部分测试用例中，Claude 在执行后期察觉到后台存在异常网络活动，尝试主动运行终止命令杀掉恶意子进程。此时 Auto Mode 的安全分类器却将 AI 自发的清理命令判定为风险操作并予以阻断。安全分类器放行了恶意进程的静默创建，却拦住了系统自身的修复指令。
Anthropic 官方在收到该漏洞报告后将其标记为 Informative（按设计运行），明确表示 Auto Mode 属于效率辅助功能，底层的意图分类属于尽力而为（best-effort）模式，并非严格的安全边界，真正的防护必须依赖操作系统的隔离机制。
攻击链各阶段表现与防御失效剖析
以下是攻击链在不同执行阶段的核心问题与防御硬伤对比：
| 阶段 | 核心问题 | 留下的硬伤 |
|---|---|---|
| 网络请求与获取 | 服务器返回 415 诱导 AI 降级到系统级 curl 命令 | 分类器将工具失败后的自主降级视为常规容错操作 |
| 资源解压与审查 | ZIP 包含恶意二进制与同名 Python 标准库伪装脚本 | 静态审查仅关注显式恶意文件，忽略了上下文重名风险 |
| 自主脚本构建 | AI 拒绝运行未知二进制，转而在不可信目录自写 Python 解码器 | 谨慎决策反成跳板，自写代码天然获得智能体信任 |
| 依赖隐式加载 | 解码器 import base64 隐式触发同目录下的恶意 struct.py | Python 默认模块搜索路径将当前目录置于标准库之前 |
| 载荷驻留与反向控制 | 恶意代码派生独立子进程并利用 claude -p 启动下级代理 | 分类器对派生进程失去上下文追踪能力，阻断清理命令 |
落地避坑指南，构建编码智能体的多层沙箱防线
依赖大模型的自律和分类器判定无法抵御精心构造的诱导攻击。在日常使用 Claude Code 或其他智能体编程工具时，必须通过外围架构建立硬性安全边界。
+---------------------------------------------------------+
| 物理机宿主系统 |
| (严禁挂载: ~/.ssh, ~/.aws, ~/.gnupg, 根目录及全局凭证) |
| |
| +-------------------------------------------------+ |
| | Docker / VM / OS 轻量沙箱容器 | |
| | | |
| | +-----------------------------------------+ | |
| | | Claude Code 运行环境 | | |
| | | - Auto Mode 仅处理本地已知文件 | | |
| | | - 外来不可信数据解压至隔离目录 | | |
| | | - 限制网络出口白名单 (Egress Control) | | |
| | | - 执行 Python 必须加 -I 参数 | | |
| | +-----------------------------------------+ | |
| +-------------------------------------------------+ |
+---------------------------------------------------------+
1. 强制在独立容器或轻量虚拟机内运行
不要在开发机主系统上直接赋予 Claude Code 自动运行权限。应通过 Docker、OrbStack 容器或轻量虚拟机（如 Lima）运行智能体，将所有文件读写和命令执行限制在瞬态环境中。
# 示例：无特权且受限的编码智能体基础容器
FROM python:3.12-slim
RUN useradd -m -s /bin/bash coder
USER coder
WORKDIR /workspace
2. 隔离敏感凭证与用户家目录
严禁将个人家目录（~）或包含敏感信息的配置文件挂载到智能体的工作空间内。必须特别注意阻断以下路径的访问权限：
~/.ssh/与~/.gnupg/~/.aws/、~/.azure/等云厂商访问密钥- 各类项目的
.env生产环境配置文件
3. 严格限制网络出口规则（Network Egress）
大多数 RCE 攻击需要连接外部服务器下载二级载荷或回传数据。通过容器网络策略或防火墙规则，阻断未授权的外网连接，仅放行必要的包管理器源地址与大模型 API 域名。
# 限制 Docker 容器对外随意连接，仅允许特定内部网络或白名单
docker run --network isolated_net --security-opt=no-new-privileges ...
4. 规范不可信数据处理命令
在提示词中或配置文件中为智能体设定执行规范。处理任何解压后的第三方代码或下载内容时，强制要求采用隔离模式执行，防止当前目录被加入模块搜索路径。
# 错误方式：直接在解压目录下运行脚本
cd untrusted_zip_dir && python3 decoder.py
# 正确方式：使用 -I 隔离模式，且在干净父目录执行
python3 -I /path/to/trusted_decoder.py --input untrusted_zip_dir/data
5. 区别对待本地项目与不可信外部输入
处理个人完全可控的本地代码重构时，可以适度开启 Auto Mode；但只要任务涉及总结外部网址、分析第三方 GitHub 仓库或解析未经验证的数据包，必须手动切回默认的逐条审批模式，杜绝智能体全自动链式执行。
综合判断
这起攻击展示了一个明确的事实：智能体安全不是提示词攻防的延伸，而是传统操作系统安全在自动化时代的重新映射。
Auto Mode 是为了提升开发流畅度而设计的自动化便利层，而不是防御恶意攻击的安全隔离层。认为大模型能够自主甄别一切恶意构造的诱导链，是对当前概率架构模型的系统性误读。凡是拥有本地工具调用权限的编码智能体，物理沙箱与网络出口控制都是不可省略的底层防线。
未解决的问题
当智能体未来需要自主处理更加复杂的全栈构建任务时，深度编译、调用系统原生依赖与外部包安装不可避免。如何在保持绝对沙箱隔离与网络访问受限的前提下，不破坏开发流的自动化协作效率，仍然是整个 vibe coding 生态尚未解决的工程痛点。
引用来源
- Embrace The Red - Breaking Claude Code Opus 5 and Auto Mode (2026-08-27)
https://embracethered.com/blog/posts/2026/breaking-claude-code-opus-5-and-automode/
- Simon Willison's Weblog - Breaking Claude Code Opus 5 Auto Mode (2026-08-27)
https://simonwillison.net/2026/Aug/27/breaking-claude-code-opus-5-auto-mode/
- IT Meets OT - Claude Code Opus 5 Auto Mode Security Observations (2026-08-12)
https://itmeetsot.eu/posts/2026-08-12-opus5_automode/
- Anthropic Claude Blog - Auto Mode as Default in Claude Code (2026-08)
https://claude.com/blog/auto-mode-default-in-claude-code
- Claude Code Documentation - Permission Modes and Execution Boundaries (2026-08)
