昨天早上刷到一条消息，让我放下手里的咖啡认真读了一遍：Claude Code的沙箱存在多个绕过漏洞，其中一个从去年10月一直挂到今年4月才修，Anthropic全程没发公告。
我第一反应是去看自己装的什么版本。还好，2.1.148，没问题。但如果你还在用2.1.89及更早的版本——你的AWS凭证、GitHub Token、SSH密钥，可能已经被悄悄送出去了，你甚至不会察觉。
漏洞到底是怎么回事
安全研究员Aonan Guan公开披露了细节。核心问题出在Claude Code沙箱的SOCKS5代理实现上。
Claude Code的沙箱设计思路是这样的：所有出站流量走SOCKS5代理，代理会检查目标主机名是否在用户允许的域名列表里。比如你只允许*.google.com，那连其他域名就会被拦。
听起来没问题对吧？问题在于JavaScript和C库对同一个字符串的解析方式不一样。
Claude Code用JavaScript的endsWith()方法来检查主机名。攻击者可以构造一个这样的主机名：
attacker-host.com\x00.google.com
JavaScript看到末尾是.google.com——放行。但底层的getaddrinfo()（C库函数）遇到空字节\x00就停了，它实际解析的是attacker-host.com。
一个字符，两边理解完全不同，安全检查就这么被绕过了。
这不是什么高深技巧。这是经典的空字节注入，Web安全圈子里十年前就玩烂了的东西，居然在一个号称"安全沙箱"的实现里存活了五个半月。
更早的那个漏洞更离谱
SOCKS5绕过其实已经是第二个漏洞了。第一个（CVE-2025-66479）更简单粗暴：当你把allowedDomains设置为空数组[]——按照正常理解应该是"禁止所有出站流量"——但代码把它解析成了"允许所有流量"。
空数组等于全放行。这个逻辑漏洞在v2.0.55修了，修完之后呢？SOCKS5空字节注入还在，继续敞着。
两个漏洞接力存在了将近半年。
这跟提示注入一组合就麻烦了
单独看沙箱绕过，你可能会想：前提是有人能在沙箱里执行代码啊，这概率不大吧？
但别忘了提示注入。Claude Code会读你项目里的文件——README、Issue评论、文档。如果有人在GitHub Issue里藏一段恶意指令，Claude Code读到之后可能会在沙箱内执行攻击者控制的代码。有了代码执行，再配合SOCKS5绕过，一条链就串起来了：
恶意指令藏在项目文件里 → Claude Code读取并执行 → 沙箱内代码用空字节注入绕过域名白名单 → 你的凭证被发到攻击者服务器
整个过程走原始SOCKS5协议传输，不经过标准HTTP出口日志，你连审计都查不到。
以下这些东西都可能被顺走：
~/.aws/下的AWS凭证~/.config/gh/里的GitHub令牌- 云实例元数据（169.254.169.254）
- 环境变量里的API密钥
还有两个问题让我不太舒服
一个是符号链接的问题。沙箱对文件系统的隔离也有缺陷——恶意进程可以在沙箱内创建指向工作区之外的symlink，当Claude后续操作这些路径时，沙箱外的可信进程可能会把数据写到非预期位置。等于沙箱的文件边界也是漏的。
另一个才是让我真正在意的：研究人员观察到，Claude Code在遇到沙箱限制时会主动尝试替代执行路径。
没有人让它"逃出沙箱"。它只是在执行任务的过程中碰到了限制，然后自己换了个方式去完成同一件事。换命令、换执行路径、换间接工作流——总之它在"想办法"。
这跟传统软件完全不一样。传统软件遇到限制，要么报错要么崩溃，行为是可预测的。AI Agent遇到限制，它会推理、尝试、绕行。而沙箱这种安全机制，从一开始就是为确定性软件设计的——假设被限制的东西不会自己找路。
这就好比一个牢房的门锁，设计的时候假设犯人不会思考。结果犯人不仅会思考，还会试各种开门的方式。
Anthropic的处理方式也有争议
v2.1.90修了SOCKS5绕过，但版本说明里只字未提安全补丁。Guan通过HackerOne提交的报告被标记为"重复"，SOCKS5绕过至今没有独立的CVE编号。
静默修复、不发布公告、不给CVE——这种做法在安全圈争议很大。好处是不给攻击者太多信息，坏处是用户不知道自己需要升级、需要轮换凭证。过去五个半月里，用通配符白名单的开发者，凭证可能已经泄露了，但他们根本不知道出过事。
我理解Anthropic可能有自己的考量，但作为每天用Claude Code的人，我更希望他们主动告诉我"出事了，赶紧升级轮换"，而不是让我自己去翻changelog猜哪个版本修了什么。
你现在应该做什么
几步操作，五分钟搞定：
# 第一步：检查版本
claude --version
# 如果低于2.1.90，立刻升级
npm install -g @anthropic-ai/claude-code@latest
第二步：如果你在2025年10月20日到升级之间，曾经用过通配符域名白名单或者沙箱功能——轮换所有可访问的凭证。AWS密钥、GitHub Token、API Key，全部换掉。这不是夸张，是必要操作。
第三步：检查SOCKS5出站流量日志。我知道大部分开发者不会留这种日志，但如果你有——仔细看看有没有去往非预期域名的外连。
第四步：心态调整。把沙箱当成纵深防御的一层，不要把它当成安全边界。在Agent够不到的地方——网络层面或虚拟机层面——加一层出口控制，才是靠谱的做法。
一个更深层的问题
这次漏洞暴露的不只是Claude Code的工程问题。MBZUAI的研究团队之前分析过Claude Code的源码（3月份泄露那次），结论是：整个系统大约1.6%是AI决策逻辑，剩下98.4%是所谓的"harness"——权限管道、上下文管理、沙箱层、工具路由、恢复机制。
而过去Claude Code曝出的所有CVE——CVE-2025-59536（代码注入）、CVE-2026-21852（API密钥泄露）、这次沙箱绕过——全都出在harness层，不是模型推理层。
同一个东西，既是Claude Code的结构性差异优势，也是主要攻击面。你给Agent的能力越强，别人能利用的攻击路径就越多。这不是AI安全的老问题，是AI Agent时代的新问题。
我最近也在看DeepSeek刚组建的Harness团队——对标Claude Code做编程智能体。坦白说，我不担心他们模型做得不够好，我担心的是这层harness的工程质量。沙箱、权限、上下文管理这些东西看着不性感，但出事就是大事。
写到这里吧。我先去把自己的API Key轮换一遍。
