Claude Code 沙箱中隐藏了 5.5 个月的漏洞导致 AWS 凭证和源代码泄露。

2026年5月20日,安全研究员Aonanguan公开报告称,Anthropic的AI编码助手“ClaudeCode”的网络沙箱存在绕过漏洞,持续时间约为5.5个月。

该漏洞是 SOCKS5 主机名中的空字节注入,影响了从 2025 年 10 月 20 日的 v2.0.24 到 2026 年 4 月 1 日修复的 v2.1.90 的大约 130 个版本。endsWith()libcgetaddrinfo()通过利用解析器差异,可以窃取 AWS 凭证、GitHub 令牌、环境变量、API 密钥等。这是继第一个绕过(CVE-2025-66479,在 v2.0.55 中修复)之后的第二个实例。

Anthropic 已将关先生的 HackerOne 报告 (#3646509) 视为重复,并且截至 2026 年 5 月 10 日尚未发布 SOCKS5 绕过的 CVE。

从: Claude Code 的网络沙箱漏洞暴露用户凭证和源代码

【编辑部评论】

在这个案例中最引起我注意的是“同一个沙箱被另一位研究人员使用不同的方法再次完全破坏”的结构是。正如奥南关本人指出的那样,两次外部调查和两次成功绕过的事实反映了“设计和操作的本质”,而不是一个孤立的错误。

首先,让我们分解一下技术细节。此漏洞属于一类称为“解析器差异”的错误。这种攻击利用了 JavaScript 和 C 语言标准库 (libc) 之间的差异,其中相同的字符串被解释为具有“不同的含义”。

具体来说,执行权限列表判断的JavaScript使用了空字节(\x00) 被视为只是一个字符。另一方面,libc,负责OS端的DNS解析,getaddrinfo()将空字节视为“字符串的结尾”并截断其后的所有内容。attacker-host.com\x00.google.com如果你扔进一个特制的字符串,比如.google.com因此,操作系统判定其正常。attacker-host.com“连接到。”这会造成一种奇怪的情况,即过滤器和执行系统在不同的主机名上“达成一致”。

我为什么现在才提这个消息?这是,以Claude Code为代表的“AI编码代理”不再是一些尝鲜者的玩物,而是开始深入企业开发现场。是。代理会接触 AWS 身份验证信息、GitHub 令牌、内部 API 端点以及各种 API 密钥等资产,这些资产如果泄露,可能会直接影响业务。沙箱正是被期望成为此类资产和人工智能行动范围之间“最后一道屏障”的机制。

从2025年10月20日沙箱普遍可用的v2.0.24到2026年4月1日发布修订版本v2.1.90,这一屏障被打破了大约130个版本和5.5个月。这并不意味着攻击是可能的。“在用户认为有围栏的期间,实际上并没有围栏”这样的说法更接近问题的本质。我有这样的感觉。

更严重的是,当这个漏洞与“即时注入”结合在一起时。将恶意指令注入 GitHub 问题评论、README 和文档,并将其读入 Claude Code。建立了一种合作游戏,其中代理遵循指令并在沙箱内执行攻击代码,并使用此旁路通过原始 SOCKS5 通信将机密信息发送到外部服务器。事实上,它是通过在正常 HTTP 通信日志中留下很少痕迹的路由导出的,这使得检测变得极其困难。

作为一名编辑,我想强调 Anthropic 回应过程中的问号。关先生的 HackerOne 报告被作为重复项关闭,因为它是“内部理解的”,并且修复程序是一个所谓的“静默补丁”,截至 2026 年 5 月 10 日没有 CVE 注册,发行说明中也没有提及安全修复程序。之前的CVE-2025-66479也是一个依赖库,而不是Claude Code本身。sandbox-runtime它仅因以下原因而被发布,严重性评分为 1.8 的 CVSS 低值(甚至发现者本人也质疑过这个评分的有效性)。

从这里你可以看到的是现实情况是,AI 行业尚未赶上“成熟的安全披露文化”。是。对于传统软件供应商来说,一个影响跨度为5.5个月、130个版本的漏洞自然会导致官方咨询并主动通知客户。随着AI代理市场持续快速增长,整个行业将如何在“快速发布”的竞争与“如实披露”的责任之间取得平衡?我们认为,这个问题肯定会影响未来公司间交易的法规、指南制定和审计要求。

研究人员自己的话清楚地表达了实践教训。“供应商提供的沙箱只是另一层防御,而不是信任线。”。代理无法到达的地方 - 主机端的防火墙、虚拟机管理程序层的出口控制、没有 IAM 角色的一次性容器、没有长期 API 密钥的开发环境 - 在公司方面拥有这些“代理无法影响的层”对于未来使用 AI 至关重要。

最后,我想补充一点积极的观点。外部研究人员进行的此类详细披露是提高整个行业安全性的推动力。像关先生这样独立的眼睛正在发挥作用,这一事实证明了生态系统是健康的、不断发展的。作为用户和公司,我们不会把它留给供应商,而是自己负责安全设计——从长远来看,这种态度将是安全地充分利用人工智能代理这一人类新工具的关键。是。

【术语解释】

沙盒
一种在隔离环境中运行程序以限制其对系统影响范围的机制。就人工智能代理而言,它用于限制身份验证信息和内部资产的范围。

网络沙箱
一种隔离方法,限制通信入口和出口(egress),以便只有授权的主机才能连接。 Claude Code 提供了一种设置允许域列表(allowlist)的机制。

袜子5
用于中继 TCP 通信的代理协议第五版。它可以调解任何 TCP 通信,而不仅仅是 HTTP,在本例中,它被用作 Claude Code 通信控制的中继点。

空字节注入
有一个“空字符(\x00)”是一种利用处理它的程序解释差异的攻击方法。分类为 CWE-158。

解析器差异
由两个或多个处理系统使用不同规则解释相同输入数据而引起的一类漏洞。对应于 CWE-436“解释冲突”。

及时注射
一种通过将原始用户无意的命令语句塞入给 AI 的输入语句中来劫持 AI 行为的攻击方法。其特点是 README 和问题注释等“普通文档”可能成为攻击媒介。

libc / getaddrinfo()
C语言标准库“libc”提供的从主机名解析IP地址的函数。按照 C 语言的约定,字符串被视为以空字符终止。

CVE(常见漏洞和暴露)
为已披露的漏洞提供的国际识别号。 MITRE 管理编号。

CVSS(通用漏洞评分系统)
以 0.0 到 10.0 的范围量化漏洞严重程度的评估指数。本案之前的漏洞 CVE-2025-66479 的评分为 1.8(低),但发现者本人对这个评分提出了质疑。

管理程序/出口控制
Hypervisor 是运行虚拟机的底层软件。出口控制是一种允许或阻止出站通信的机制,通过防火墙、云网络设置等实现。

沉默补丁
一种静默修复漏洞的方法,无需在发行说明中明确提及。用于指不涉及发布 CVE 或官方通报的案例。

[参考链接]

人智官方网站(外部)
开发克劳德代码的美国人工智能公司的官方网站。我们进行安全研究并提供各种人工智能产品。

克劳德代码官方文档(外部)
Anthropic 提供的 AI 编码代理的官方文档。公开了安装步骤、设置方法和更改历史记录。

克劳德代码 GitHub 存储库(外部)
一个可公开获取 Claude Code 源代码和发布历史记录的存储库。还将发布安全公告。

黑客一官方网站(外部)
调解漏洞报告和赏金计划的平台。关先生也从这里报道了此事。

NVD(国家漏洞数据库)(外部)
由美国国家标准与技术研究院 (NIST) 运营的漏洞数据库。 CVE 编号和严重等级已公开。

GitHub 咨询数据库(外部)
由 GitHub 运营的安全咨询数据库。它聚合了开源漏洞信息。

CVE-2025-66479 GitHub 安全通报(外部)
这是有关沙箱绕过的第一个正式公告。为沙箱运行时发布。

关奥南的博客(外部)
发现此漏洞的研究人员的个人网站。整理了过去人工智能安全研究和讲座的信息。

[参考文章]

第二次,相同的沙箱:另一个人类克劳德代码网络沙箱绕过可实现数据泄露(外部)
发现者关先生本人于2026年5月20日的公开报告。它详细介绍了大约 130 个版本和 5.5 个月的受影响范围和复制代码。

Anthropic 默默修补 Claude 代码沙箱绕过问题(外部)
《安全周刊》报道。总结了两种旁路的背景以及与即时注入相关的风险。

就连克劳德也同意:沙盒中的漏洞是真实且危险的(外部)
据《登记册》报道。它讲述了五个月内两次无声修改的故事以及研究人员的隶属关系。

克劳德代码沙箱缺陷暴露了凭证和源代码(外部)
由 Cyber​​press 报道。它总结了 HackerOne#3646509 的处理历史以及用户应采取的具体步骤。

CVE-2025-66479:Anthropic 的静默修复和 Claude Code 从未获得的 CVE(外部)
关先生的博客记录了他的第一次绕行。发现者自己对CVSS 1.8评价的疑虑也明确提出。

[相关文章]

Claude Code 存在三个严重漏洞,存在通过配置文件接管机器的风险(2026年2月26日)
Check Point Research 在 Claude Code 中发现了另外三个漏洞。解决 AI 编码代理的配置风险,例如 MCP 同意绕过和 API 密钥盗窃。

Anthropic MCP 协议中的系统漏洞可能影响 1.5 亿次下载(2026年4月18日)
Ox Security 覆盖了 MCP 中发现的系统漏洞。与本文一样,Anthropic 对漏洞披露的立场是一个争论点。

Anthropic 的 MCP Inspector 存在致命缺陷 |关于代理人工智能安全的警报(2025年7月13日)
这一案例引起了人们对代理人工智能安全性的警惕。作为本文的史前背景,我们可以总结一下人工智能代理的风险。

[编者后记]

你是否曾经仔细检查过你平时使用的AI编码代理对事物的权限有多大?我意识到我太沉迷于便利,以至于我花了很多时间忘记了代理幕后正在进行什么样的通信。我不认为这个案子是为了阻止人工智能。

相反,我觉得我们已经进入了这样一个阶段:那些能够用自己的语言来区分什么应该留给人工智能,什么应该留给人类继续掌控的人将会变得更强大。您的团队如何开发人工智能代理的权限设计?请随时与我们分享您的想法和想法。