2026-08-11 04:32:03 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文章报道了2026年8月第一周发生的三起严重供应链安全事件:ChainDrop恶意软件感染超1300个npm包,月下载量达20亿次,窃取开发者凭证并自我传播;OpenVSX市场发现77个伪装成合法工具的恶意扩展;HalluSquatting攻击利用AI编程助手的幻觉推荐恶意包。文章提出三条防御建议:依赖锁定与完整性验证、令牌权限最小化、审查AI生成的代码依赖。 综合评分： 85 文章分类： 供应链安全,恶意软件,漏洞分析,安全意识,渗透测试

cover_image

你的代码里，藏着黑客埋的”毒”：1300个 npm 包遭供应链投毒

原创

欢迎关注→ 欢迎关注→

安全客

2026年8月10日 10:55 北京

在小说阅读器读本章

去阅读

ChainDrop 恶意软件感染超 1300 个 npm 包，月下载量达 20 亿次，窃取开发者 npm/GitHub/云凭证并自我传播。同期 Open VSX 发现 77 个伪装成合法工具的恶意扩展。软件供应链正在经历最严重的信任危机。

如果你在昨天更新了一个 npm 依赖包，你的开发凭证可能已经被传到了攻击者的服务器上。

这不是危言耸听。8 月第一周，安全圈连续拉响三个供应链安全警报。先说最严重的那个——ChainDrop。

ChainDrop：一场精心策划的 npm 大屠杀

ChainDrop 恶意软件的规模让最资深的供应链安全研究员都倒吸一口凉气。超过 1300 个 npm 包被感染，这些包的月下载量合计达到 20 亿次。

20 亿次，什么概念？这意味着地球上每四个人里，就有一个人”可能”间接使用了这些被投毒的包。当然会有重复下载，但这个数量级已经说明了一切——这不是一次对特定目标的攻击，而是一次对全球开发者生态的无差别扫射。

ChainDrop 的攻击链条设计精巧得让人不寒而栗。被感染的 npm 包并不会立即”爆炸”，而是静默地在开发环境中运行。它做了三件事：

第一步，收集 npm Token。你在本地的 .npmrc 文件里的认证令牌，被它悄悄读取并发送到远程服务器。

第二步，窃取 GitHub 凭证。它扫描你的 SSH 密钥和 Git 配置，获取对代码仓库的访问权限。

第三步，自我传播。拿到你的 npm Token 之后，它不是就此收手——而是利用这个 Token 登录你的 npm 账号，向你的其他包也注入恶意代码。

攻击者的意图很明确：他们不只是想要一次性的数据窃取，而是在建立一个不断自我繁殖的恶意网络。每感染一个开发者，就能感染更多的包；每感染一个包，就能捕获更多的开发者。

77 个”孪生恶魔”：Open VSX 的伪装攻击

同一天，另一个让人头疼的消息从开源 IDE 扩展市场传来。

Open VSX 市场（VSCode 等编辑器的扩展商店）移除了 77 个恶意扩展。这些扩展玩的是一个”孪生”策略——取一个和知名开发者工具极为相似的名字，让用户以为自己在安装一个熟悉的工具。一旦安装，它们就开始收集主机名、仓库信息、CI 环境数据和开发凭证。

这 77 个恶意扩展总下载量超过百万次。攻击者把”鱼目混珠”玩到了极致：有的伪装成 Docker 集成工具，有的伪装成 Git 增强插件，还有的伪装成代码片段管理器——都是开发者日常开发离不开的功能。

HalluSquatting：AI 幻觉成了帮凶

如果说上述两种攻击是对”人类信任”的利用，那么 HalluSquatting 则开辟了一个全新的战场：攻击 AI 的信任。

这种攻击手法的核心思路堪称天才：既然 AI 编程助手（如 GitHub Copilot、Cursor、Claude Code）会产生”幻觉”——推荐不存在的代码包——那攻击者要做的，就是把这些”幻觉”变成现实。

过程是这样的：AI 编程助手在生成代码时，可能会推荐一个实际不存在的包名（比如 security-checker-pro）。这是 AI 根据训练数据中的命名模式”编”出来的。攻击者会定期扫描这些 AI 推荐的”幻觉包名”，一旦发现某个包名被高频推荐但不存在，就抢先注册它——里面的代码是恶意的。

然后你作为开发者，让 AI 帮你写了一段”安全检查”的代码，AI 自动 import security-checker-pro。你安装了它，因为这是 “AI 推荐的”。攻击者的恶意代码就在你的生产环境中运行起来了。

这已经不是人类被欺骗。是 AI 被欺骗后，AI 再欺骗了你。

供应链安全的”木桶效应”

这三件事在同一天登上头条，不是偶然。它们指向了同一个残酷现实：软件供应链的每一个环节，都有可能成为攻击入口。

npm 生态有超过 300 万个包，每天有数万个新版本被发布。VSCode 扩展市场有数万个扩展，每个扩展都可能读取你的文件系统。AI 编程助手每天都在生成数百万行代码，其中包括大量第三方依赖的导入语句。

过去我们谈供应链安全，聚焦在”我直接依赖的包是否安全”。ChainDrop 和 HalluSquatting 告诉我们，这个思路已经彻底过时了。攻击面已经从”你依赖的包”，扩展到”生产你依赖产品的每一个 AI 工具和自动化环节”。

怎么办：三条防线

面对这波供应链攻击，三条防线迫在眉睫。

第一条防线：依赖锁定 + 子资源完整性。 不要信任任何一个自动更新的依赖。把直接依赖和间接依赖的版本、哈希值全部锁死在 lockfile 里。不要用 npm install 跳过 package-lock.json。这不是什么新鲜建议，但看了ChainDrop 的规模之后，你应该知道这个建议有多重要了。

第二条防线：令牌权限最小化。 npm Token 不要给 publish 权限，除非你真的要发布包。GitHub Token 不要给 repo 全量权限，按仓库逐个授权。CI 环境的凭证不要和个人开发的凭证混用。每一次权限的过度授予，都是给攻击者留的门。

第三条防线：审查 AI 生成的代码依赖。 在 AI 帮你写了 import xxx 之后，去 npm 搜一下这个包是不是真实存在、最后一次更新是什么时候、维护者是谁。如果一个包的维护者是一串乱码邮箱、没有 README、上周刚注册——这就是一面巨大的红旗。

总结

供应链攻击从”可能发生”到”正在发生”，只用了几年的功夫。从 ChainDrop 的 1300 个包，到 Open VSX 的 77 个假扩展，再到 HalluSquatting 的精确围猎——攻击者比你更了解你使用的每一个工具链条。

你的代码不是孤立的。它依赖着成千上万个”别人的代码”，而”别人的代码”来源可能是一个被 AI 幻觉生成的包名，然后被一个蹲点的攻击者抢注。任何一环断裂，整个链条都会崩塌。

这一次，1300 个包被污染。下次呢？