文章总结： Anthropic的ClaudeCode工具源代码泄露后被发现存在环境变量注入漏洞，虽然被评级为低危但暴露了更深层信任模型问题。漏洞允许服务端无限制修改客户端环境变量，在远程工作模式下可能造成代码执行、流量劫持等风险。文章指出根本原因在于AI工具仍沿用单向信任模型，建议采用零信任原则设计安全边界。 综合评分： 82 文章分类： 漏洞分析,安全建设,云安全,解决方案,AI安全

Claude Code源码泄露：一个低危漏洞，暴露了一个大问题

幻泉之洲

2026年4月13日 13:39 北京

在小说阅读器读本章

去阅读

Anthropic旗下的Claude Code工具源代码被公开，安全研究人员从中发现了一个环境变量注入漏洞。这个漏洞虽然被评级为“低危”，但它暴露了一个更深层次的信任模型问题：在远程工作模式下，工具过度信任了它所连接的服务端。

2026年3月底，Anthropic的代码助手工具Claude Code的源代码被意外公开。这立即引来了一波安全审计。很快，一个漏洞被确认了。

先说结论：这个漏洞本身的严重性被定为“低”。它更像是一道冗余防线上的缺口，本身不致命。但我们仔细看了之后，觉得事情没这么简单。Anthropic给Claude Code配备了审查、安全以及专门的审计工具，即便如此，还是有改进空间。这本身就说明点什么。

漏洞详情：不设防的环境变量写入

问题出在Claude Code的结构化输入输出层。这个模块通过传输协议接收一种叫update_environment_variables的消息。processLine方法处理这个消息时，会直接把发来的键值对塞进process.env里。

if (message.type === ‘update_environment_variables’) {  const keys = Object.keys(message.variables)  for (const [key, value] of Object.entries(message.variables)) {    process.env[key] = value  } }

这个功能的本意是好的，只是为了方便更新一个会话令牌（CLAUDE_CODE_SESSION_ACCESS_TOKEN）。但它的实现方式太粗放了：它允许写入进程里的任何一个环境变量，没有白名单限制。

一个本该只能更新特定令牌的功能，却开放了整个环境变量的写入权限。这就好比为了开一扇窗户，却把整面墙给拆了。

攻击场景：远程工作模式下的信任危机

在本地命令行模式下，这个问题不大，因为通信发生在父子进程之间，双方默认是可信的。真正的风险发生在“远程工作者”模式下。

在这种模式下，Claude Code会通过WebSocket或SSE连接到一个会话入口服务器。关键在于，RemoteIO类会把从服务器收到的任何传输数据，不加过滤地直接灌进processLine()方法。更关键的是，服务器并不会向客户端证明自己的身份。

流程是这样的：Claude Code会发送一个Bearer令牌来证明自己的身份，但完全没有机制去验证对面的服务器是不是可信的。这是一种单向信任。

安全研究团队做了个概念验证，搭建了一个恶意的WebSocket服务器。服务器发出一条消息，通过update_environment_variables设置NODE_OPTIONS环境变量，让它加载一个恶意的JavaScript文件。当Claude Code连接后，一旦它启动一个子Node.js进程，预设的恶意代码就会执行。他们用这种方法成功地在测试机器上留下了一个标记文件，证明了远程代码执行的可行性。

除了远程执行代码，这种机制还能干很多其他事：

• 通过设置ANTHROPIC_BASE_URL变量，可以把API调用和OAuth认证流程重定向到攻击者控制的服务器，从而窃取凭证和会话内容。
• 设置HTTPS_PROXY，可以把所有HTTPS流量都导向攻击者的代理服务器。
• 设置NODE_TLS_REJECT_UNAUTHORIZED=0，可以完全关闭TLS证书验证，中间人攻击就变得轻而易举。

说白了，在这个远程模式下，服务端可以对工作程序的运行环境进行不受限制的控制。客户端的身份认证，并不能保证服务端发来的指令是可信的。

问题的根源：信任模型错了

这个漏洞的修复简单到令人尴尬：加一行代码，搞个白名单，只允许修改以CLAUDE_CODE_开头的环境变量就行。

那么，为什么一开始没这么做？

我个人觉得，这不仅仅是疏忽。这里暴露了一个在构建AI工具时常见的思维定势：我们总是默认“服务器是好的”。

这套逻辑在传统的B/S架构里或许成立，服务器通常是自己或可信伙伴掌控的。但Claude Code的远程工作模式很可能被用在更复杂的场景里，比如连接第三方平台、云服务商或者客户自己搭建的网关。在这种环境下，你连接的那个端点，本身就可能是不可信的，或者可能会被攻陷。

从这个角度看，这个低危漏洞其实捅破了一层窗户纸：我们给AI工具设计安全边界时，可能还没完全适应它们要面对的新环境。它不再是运行在封闭环境里的单个应用，而是一个可能要和外部世界各种端点交互的智能体。单向的信任模型，在这里是失效的。

一点反思

Anthropic的反应很专业，收到报告几天内就确认了技术分析。整个报告是公开的，源代码的审核过程也很透明。

这次事件真正的价值，不是发现了一个能被很快修复的代码缺陷。它更像是一个提醒，提醒所有在构建AI原生工具的团队：

随着这些工具的功能越来越强，应用场景越来越广，它们的安全模型也必须跟着升级。过去那种基于固定边界的假设，需要被基于零信任或最小信任原则的设计所取代。客户端不仅要证明自己是谁，也需要有能力验证它在和谁对话。

说白了，当你的AI开始帮你在网络上“跑腿”时，你得确保它别随便从一个陌生人手里接过“包裹”。即使那个陌生人自称是“服务站”。这个Claude Code的漏洞，就是接过了不该接的东西。修复代码容易，但修复这个信任模型的设计思路，可能需要想的更多。

参考资料

[1] https://audited.xyz/blog/claude-code

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《Claude Code源码泄露：一个低危漏洞，暴露了一个大问题》