Operation PowerOFF：AI代码泄露的供应链浩劫
2026年3月某日，Anthropic的工程师在发布Claude Code npm包时，手一滑，把不该放出去的东西一块儿打了进去。
一个59.8MB的ZIP文件，就这样装着51.2万行TypeScript源代码，流入了互联网。
这个消息本身已经够震撼了。但真正让安全圈睡不着觉的，是接下来发生的事——以及那些泄露代码里，藏着多少不该被外人知道的东西。
本文把这件事彻底拆开来讲：泄露了什么、攻击者看到了什么、供应链攻击是怎么一步步来的、企业现在该怎么应对，以及我们该从这件事里学到什么。
—
一、事件回顾：一个失误是怎么演变成一场浩劫的
那一天到底发生了什么
Anthropic在发布Claude Code的npm包时，内部操作流程出了问题。原本只该打包发布的编译产物，不知道怎么把源代码映射文件（source map file）也给塞进去了。
Source map是干嘛的？说白了就是”调试用的地图”——有了它，浏览器里能直接看到原始代码，而不是压缩成一团的乱码。开发者自己调试产品时，这个功能挺好用的。
但这次Anthropic的问题是：他们把这个地图连着完整路线图一起打包发出来了，等于把设计图纸白送给了所有人。
事情经过大概是这个样子：
Anthropic的包一上线，全球各地的开发者在更新依赖的时候顺手就装上了。有人发现包里的内容不对劲，顺手把ZIP从Anthropic自己的Cloudflare R2存储桶里直接拖了下来。紧接着GitHub上开始出现大量镜像，有人整理、有人分析、有人星标——48小时内，相关仓库星标数突破8.4万，分叉数超过8.2万。
这个传播速度，Anthropic自己的响应团队根本追不上。
等Anthropic反应过来发DMCA通知的时候，代码早就在无数服务器、个人电脑、NAS和备份硬盘里安家了。想删？删不干净的。
泄露代码揭示了什么
如果说代码本身只是让攻击者省了点阅读理解的时间，那接下来要说的这些，才是真正让人后背发凉的部分。
内部AI路线图暴露。 源码里出现了好几个还没发布的模型代号：Capybara（对应Claude 4.6）、Fennec（对应Opus 4.6），还有一个叫Numbat的不知道什么项目。但更扎眼的是数据：Capybara v8版本的虚假信息率高达29-30%，而v4版本这项指标只有16.7%。下一代模型的”幻觉”问题，可能比官方宣传的要严重得多。
记忆系统的架构细节曝光。 Claude Code的分层记忆系统一直是它区别于普通代码助手的重要特性。这次泄露把架构细节扒了个精光：小型索引跟踪位置而不是存储完整数据、实际信息仅在需要时检索、失败的更新不会影响AI整体记忆。这些细节等于给攻击者画了一张”这里有盲区”的地图。
KAIROS：被忽视的隐形炸弹。 这个功能允许Claude Code作为”始终在线的后台代理”运行——也就是说，在用户不知道的情况下，AI可以在后台持续运行命令、访问文件、甚至发送网络请求。如果这个功能被恶意prompt劫持，或者被攻击者利用，那后果绝不是普通钓鱼攻击能比的。
—
二、攻击者视角：他们看到了什么机会
安全护栏变成了”明码标价”
Claude Code内置了多道安全护栏，防止用户诱导AI执行恶意操作。这是大语言模型厂商的标准做法。
但源码一泄露，护栏的位置、高度、材质全摆在桌面上了。
攻击者可以精确地测试：哪些指令能触发安全护栏，哪些边界情况还没被覆盖，护栏和护栏之间有哪些”夹缝”可以利用。以前需要靠”盲测”来找漏洞，现在有了图纸，效率完全不一样了。
记忆系统的盲区可以被利用
Claude Code的分层记忆有个特点：失败的更新不会影响AI整体记忆。这个设计本身是合理的——防止某次操作失败导致整体崩溃。
但换个角度想，如果攻击者有办法让某个记忆写入操作失败，同时又让另一个操作成功，就可能造成记忆状态的不一致。不一致的记忆状态，可能导致信息泄露，也可能导致指令注入。
这不是理论上的风险。 这种”失败但没完全失败”的边界条件，恰恰是渗透测试中最喜欢找的切入点。
最讽刺的地方：GitHub的传播速度，比npm的修复速度快太多
安全研究员”ojasookert”发布分析指出：Anthropic需要发布新版本的npm包来修复这个问题。但npm包一旦被安装到全球的开发环境和CI/CD系统里，官方补丁的覆盖率，远远追不上社交媒体和开发者社区的传播速度。
说白了：补丁还在路上，攻击者已经拿着源码开始研究攻击路径了。
—
三、供应链攻击五步还原：你的电脑是怎么被盯上的
这件事最值得警惕的地方，不只是Anthropic自己的失误，而是接下来发生的事情——有人开始利用这次泄露做坏事。
第一步：分叉，建立恶意镜像
攻击者把泄露代码fork到自己的GitHub仓库，命名极具诱惑性：Claude Code Leak Unpacked、claude-code-full-source、Anthropic-Leaked-Source-Analysis……
命名原则很明确：利用开发者的好奇心 + 搜索优化。 很多人会直接去GitHub上搜”claude code leak”，这些仓库就会出现在搜索结果里。
第二步：注入，植入恶意payload
在代码里添加恶意依赖、Git hooks、MCP服务器配置，或者直接植入后门脚本——这一步才是真正危险的地方。
已知案例：有人把恶意仓库命名为idbzoomh，内藏Rust编写的dropper，释放Vidar窃密木马和GhostSocks代理。一旦开发者下载运行，机器上所有能偷的东西打包传走。
第三步：传播，利用GitHub推荐算法
GitHub的推荐算法会给高star、高fork的仓库更多曝光。攻击者通过多个账号互相star、fork，快速推高仓库的热度。
同时，利用开发者搜索”claude code leak”的自然流量，在issues和discussions里伪装成”技术讨论”，进一步提升可信度。
第四步：执行，开发者自己把恶意代码装进来
这步最讽刺的地方在于：攻击者几乎不需要自己动手。开发者会主动把恶意代码装进自己的开发环境——通过npm install、pip install，或者在CI/CD管道里自动触发。
“我只是想看看泄露的源码而已”，这句话说出来你自己信吗？
第五步：窃取，达成攻击目标
恶意代码执行后，攻击者的收获包括但不限于：SSH密钥、API Token、环境变量里的数据库连接字符串、浏览器存储的密码、开发机上的商业机密代码。
然后就是横向移动——从你的开发机，渗透到你们公司的内网。
—
四、已发现的恶意分叉：有人在趁火打劫
Zscaler的安全研究团队已经确认，至少有一个恶意分叉在GitHub上传播，同时可能还有更多没被发现的。
idbzoomh仓库是目前已确认的恶意分叉之一。攻击者伪装成”Claude Code泄露代码备份”，实际上内藏Vidar窃密木马和GhostSocks代理。一旦运行，机器上的凭证、密码、密钥全部打包传走。
Zscaler还指出，泄露代码中涉及的已知漏洞正在被武器化：
| 漏洞编号 | 影响 | 武器化状态 |
|———|——|———–|
| CVE-2025-59536 | 恶意配置文件触发 | 已验证可利用 |
| CVE-2026-21852 | MCP服务器注入路径 | 已确认攻击路径 |
攻击路径包括：
- 通过恶意npm配置文件触发漏洞
- 在.git/hooks里植入后门脚本
- 篡改MCP服务器配置，拦截AI与外部工具的交互数据
- 最终实现任意shell命令执行或凭证窃取
—
五、企业与开发者自检清单：现在该做什么
立即行动（今天之内）
停止从非官方渠道安装Claude Code。 官方来源只有一个：Anthropic官方GitHub账号下的仓库，以及npm官方仓库。其他任何分享链接、网盘链接、别人发的”完整源码备份”，一律不要碰。
检查你最近有没有装过问题版本。 时间窗口是2026年3月下旬到4月初。如果这期间你更新过Claude Code，立刻确认版本：npm list @anthropic-ai/claude-code 或 pip show claude-code。
扫一下开发环境有没有异常依赖。 用npm audit、Socket.dev，或者公司现有的安全扫描工具，检查package.json和requirements.txt有没有新出现的不认识依赖。重点盯.git/hooks目录有没有被改过。
如果你的开发环境涉及高度敏感系统，考虑轮换凭证。 包括项目的API Token、CI/CD系统凭证、数据库连接字符串。这不是过度反应，是标准的”假设已被攻陷”排查流程。
中期防御（这一周）
引入依赖签名验证。 npm 9以上的版本支持npm audit signatures，可以验证包的来源完整性。GitHub Actions里也要加上依赖审查步骤。
在CI/CD管道里加恶意代码扫描。 推荐工具：Socket.dev、Dependabot、Snyk。这几个都能在构建阶段发现问题包。
建立第三方代码引入审批流程。 以后任何AI工具的npm包、pip包引入开发环境，必须走安全审核流程，不能因为”官方的”就无脑装。
长期方案
供应链安全体系建设。 软件物料清单（SBOM）全覆盖，依赖可溯源、可验证，定期安全审计。这是正经公司早晚要做的，现在只是被这件事催着提前做。
AI工具使用安全政策。 明确哪些AI工具在哪些场景可以用，禁止在工作中使用个人账户安装的AI工具处理公司项目，敏感代码和商业机密绝对不能粘贴给AI工具。
—
六、AI时代的代码安全：三个必须打破的认知
认知一：开源不等于安全
传统安全圈的共识是：开源代码透明、漏洞可见、社区监督，所以比闭源安全。
Claude Code事件把这个认知打了个稀碎。
AI工具的特殊性在于，它不只是处理数据，它本身就是数据和逻辑的混合体。你在AI工具里处理的，可能是你自己产品的核心代码、你们的商业策略、你客户的私密数据。泄露源码等于同时泄露了”AI知道什么”和”AI怎么想”。
透明度在这里是双刃剑。 代码越透明，攻击者的路线图就越清晰。
认知二：AI工具的安全风险是供应链风险
很多人把AI工具当作”用完即走”的工具，没有把它们当成需要持续管理的软件资产。
但实际上，AI工具一旦安装进开发环境，它就和你的依赖链牢牢绑在一起了。它出问题，你的整个开发环境都受影响。
npm这次暴露的问题，本质上和2021年的Log4j没有区别：一个源头出问题，数千个项目跟着遭殃。只是这一次的主角换成了AI工具。
认知三：开发者社区的每一次”传播”都是在帮攻击者
Anthropic的失误是这件事的起点，但整个开发者社区在传播这些代码时的热情，客观上也加速了风险的扩散。
8.4万星、8.2万分叉——这其中有多少人是真的在安全研究，有多少人只是出于好奇下载了一份”备份”，然后不知道放哪儿了？
面对”泄露源码”这种信息，保持克制和审慎，是对厂商的尊重，更是对自己安全的保护。 你不知道你随手保存的那份代码，会以什么方式在什么时候给你挖一个坑。
—
结语
AI工具的崛起让开发效率提升了不止一个台阶，但我们也正在把越来越多的信任交给这些工具。
Claude Code这次的失误，暴露的不只是技术问题，更是一个关于”如何在效率和安全之间找平衡”的时代命题。
供应链安全这件事，以前是安全团队的专属工作。现在，每个用AI工具写代码的开发者，都已经是这条链上的一环了。
你用过来历不明的AI工具代码吗？你们公司有供应链安全的相关流程吗？ 欢迎在评论区聊聊你的经历，或者直接联系我们交流。
—
*作者：点滴安全 · 首发于 www.dripsafe.cn*