Claude Code 源码泄露事件复盘:一次典型 npm 发布事故,给所有开发者敲响警钟

sourcemap 原本是给开发和调试使用的。构建后的 cli.js 往往已经被打包、转译甚至压缩，不容易直接定位到原始 TypeScript 源码。于是构建工具会额外生成一个 .map 文件，告诉调试器“这段打包后的代码，对应原来哪一个源文件、哪一行、哪一列”。如果这个 sourcemap 只包含位置信息，问题还不算太大；但如果它还包含 sourcesContent 字段，那么原始源码文本就会被直接嵌进 .map 文件里。

这就意味着，一旦这个 sourcemap 被一起发布到 npm registry，任何能够下载该包的人，不需要攻入内部系统，也不需要具备很强的逆向能力，只要解析 .map 文件，就可能把原始源码逐文件恢复到本地。换句话说，泄露的不是“几段实现逻辑”，而是“很大一部分能够直接阅读和研究的原始工程代码”。

从影响上看，这次暴露的主要是 Claude Code CLI 和相关工具链实现细节，包括内部能力边界、功能开关、部分实验性功能痕迹，以及工程层面的提示词编排、记忆机制等。这类信息对普通用户而言可能只是“看个热闹”，但对安全研究者、竞争对手以及供应链攻击者来说，价值并不低。它不是模型权重泄露，也没有证据表明 Anthropic 内网被攻破，但它确实让外部世界更容易理解这个产品的内部实现方式。

如果把这件事抽象成一个工程问题，其链路其实非常典型：

1. 构建阶段生成了对调试有用的 sourcemap。

2. 发布阶段没有把这个 sourcemap 排除掉。

3. sourcemap 中又包含了可直接恢复源码的 sourcesContent。

4. 结果是“本来只是想发布可执行产物，最后却等于把源码一并公开了”。

因此，这次事故真正暴露出来的，不只是 Anthropic 的一次失误，而是许多团队共同存在的一个盲区：大家会检查源码仓库里有没有敏感内容，却不一定会认真检查“最终发布出去的 tarball 里到底装了什么”。

第一，泄露版是否真的会把 sourcemap 发出去。

结果是肯定的。执行 npm pack –dry-run 后，打包清单里明确出现了 dist/cli.js.map。

这说明只要发布配置不收紧，sourcemap 就会像普通产物一样进入分发链路。

第二，拿到 sourcemap 之后，是否真的可以恢复源码。

结果同样是肯定的。实验中使用了一个简单恢复脚本，直接读取 .map 文件里的 sources 和 sourcesContent，把源文件逐个写回本地。恢复结果成功落出了原始 src/cli.ts，并且命中了预埋的标识字符串 LEAKY_MARKER_2026_03_31。

这说明恢复过程并不是“艰难逆向”，而是“把已经藏在 map 里的源码重新导出来”。

这里需要特别注意一个边界：目前并无充分证据表明某个具体 GitHub 仓库已经存在恶意投毒行为，也不宜在未经核实的情况下简单定性。但从供应链安全角度看，这类项目天然就属于高风险对象，原因很简单。

第一，用户对“能跑起来的现成项目”往往缺乏足够警惕。

很多人看到“Claude Code 开源镜像”“修复版 Claude Code”“可直接安装版 Claude Code”就会去 npm install、pnpm install、bun install，甚至直接运行别人仓库里的安装脚本。问题是，这类仓库最容易藏匿恶意后门的地方，恰恰就在依赖安装和首次启动阶段，比如：

• postinstall、prepare、preinstall 等 npm 生命周期脚本；

• 下载额外二进制文件的 shell 脚本；

• 读取本机环境变量、SSH key、云服务 token 的初始化逻辑；

• 把数据悄悄发往第三方服务的埋点或远程加载模块。

第二，这类项目很容易借“官方事故”获取信任红利。

一旦官方项目出过安全事故，很多用户会下意识寻找“民间修复版”“社区增强版”“还原版源码”。而攻击者最擅长的，就是在这种高关注、信息混乱、用户急于尝鲜的窗口期，把恶意代码伪装成“社区贡献”或“修复补丁”。

第三，AI 工具类项目本身就具有更高的权限敏感性。

像 Claude Code 这类工具通常会接触：

• 本地代码仓库；

• Shell 命令执行权限；

• 开发者 token、Git 凭证、云服务环境变量；

• 编辑器配置、SSH 配置和历史命令。

也就是说，一旦运行的是一个被投毒的二次开发版本，它的危害不只是“程序跑坏了”，而可能是直接把本地研发环境里最有价值的东西一并带走。

对此，建议重点做好以下防范：

1. 优先使用官方渠道分发的版本，不要因为“能看见源码”就放松警惕。

2. 对任何 GitHub 上的二次开发版本，先看维护者身份、提交历史、发布时间、star 增长是否异常，再决定是否接触。

3. 安装前先看 package.json、安装脚本、生命周期脚本和网络请求逻辑，尤其是 postinstall。

4. 不要在有生产权限、真实密钥、公司内网访问能力的机器上直接试跑未知来源版本。

5. 最好放到隔离环境、一次性容器或专门的测试机中验证。

这也正是此次事件真正值得警惕之处：源码泄露本身已经是事故，但在事故之后形成的“二次传播 + 二次开发 + 非官方分发”链条，往往才是对开发者更现实、更长期的风险。

你对这个事件怎么看？对于AI编程工具的安全性，你有什么担忧或建议？欢迎在评论区分享。