Claude Code Auto Mode 被攻破实录
Breaking Claude Code Opus 5 Auto Mode
Anthropic 曾宣称 Opus 5 在 Auto Mode 下的提示词注入攻击成功率为 0.00%，但我通过精心设计的攻击链，将成功率提升至 60% 至 80%。攻击利用 HTTP 415 错误诱导模型从 WebFetch 切换到 curl，下载包含恶意 struct.py 的 ZIP 包。当 Claude 拒绝运行二进制文件并自行编写 Python 解码器时，触发了模块遮蔽漏洞，导致远程代码执行。更讽刺的是，当模型意识到被入侵并试图清理时，Auto Mode 的安全分类器反而阻止了清理命令。这证明 Auto Mode 仅是便利功能而非安全沙箱，真正的防线仍需依赖操作系统隔离。
如果你关心正在发生的事情，并担心对齐问题、幻觉和提示词注入，那么 Auto Mode 绝不能替代在隔离环境中运行代理并监控其行为。
HN 评论区
107- andai
但它是在攻击者控制的目录（解压后的归档）中运行该解码器。
那里有一个恶意的 struct.py 文件，遮蔽了 Python 的标准实现。
我自己也遇到过这种情况：我给某个文件起了个随机名字，结果它意外遮蔽了某个 Python 标准库模块，导致我遇到了史上最奇怪的启动崩溃。
这绝对不像是一个合理的设计：魔法般地静默导入你看到的一切，并覆盖基本功能。
- colinmarc
我觉得这有趣的地方在于，它专门针对 Claude 特有的行为模式。Anthropic 创造了一个模型，它会可靠地调用相同的工具（是的，还有相同的短语；`python -c` 对它来说是一个关键工具）。大家都用的是同一个模型，所以只要摸清模型的行为模式，就能更精准地针对它。
- rcxdude
我其实不会把这称为提示注入攻击，因为它并没有真正劫持代理使其变得恶意（文章后面确实讨论了这一点）。这更像是一个特洛伊木马，专门用来欺骗 Claude。
- kstenerud
这只是我运行代理时进行沙箱隔离的众多原因之一（也是我编写代理沙箱软件的原因）。
有一次，我发现我的 Claude 代理抱怨无法连接到 https://some-weird-domain.com，因为它说网络断了（我在代理不需要网络时会禁用沙箱中的网络，并代理 API 连接）。我问它为什么去连那个地址，它告诉我那是因为我让它去的。
我从未找到任何提示注入的证据，但这绝对让我变得疑神疑鬼。
- comboy
很有趣的攻击，设计得非常巧妙。不过我不确定这和 auto mode 本身有多大关系。
- hahn-kev
作为一个非 Python 开发者，系统库仅仅因为同目录下存在一个特定名称的文件就被修改，这种行为让我感到非常惊讶。
- alkonaut
沙箱化的问题在于，常规的开发者环境（庞大的 IDE、克隆的巨型仓库、已安装的依赖项等等）很难轻松地进行沙箱隔离。我无法为运行 claude cli 设置一台“第二台机器”或一个“隔离环境”。至少，在虚拟机、物理硬件或容器等意义上做不到。目前还不清楚关于白名单工具/目录等的最佳实践是什么，但到目前为止，我发现唯一有用的模式就是“允许一切，然后去喝杯咖啡”。虽然感觉这样并不妥当，但现状如此。
- pvillano
LLM 本质上就是不可验证且不可信的。训练数据可能是错误的、恶意的、被审查的，或是为了服务于母公司而被篡改的。模型本身就是一个黑盒。安全的输入是不可能的：你无法摆脱自然语言，也无法将命令和数据分离成不同的流。输出是随机的，平均表现优于任何算法，但在单个案例上没有任何保证。
所有这些都无所谓，因为 LLM 只是一个纯文本接口。它无法伤害计算机，因为它无法执行操作。
那你他妈为什么要给它一个 shell 呢？
显然，这是为了打造一个能尽可能快地做任何事情的产品。你一天就能做出一个基于 shell 的框架。既然竞争对手都有基于 shell 的框架，那么任何想跟上步伐的 AI 公司也必须如此。他们永远被困在试图封堵攻击面漏洞的困境中，而这个攻击面之广，堪比书面语言本身。解决这个不可能的问题，需要像“使用第二个不可信的 LLM 来验证第一个遵循互联网指令的不可信 LLM 的输出”这样天才般的想法。