核心提要： 目前已发现数百个遭入侵的 NPM 包，且受影响列表仍在持续增加 — 一场大规模供应链攻击正通过恶意软件迅速扩散。黑客在 CrowdStrike 的 NPM 包及其他广泛使用的代码库中植入恶意脚本，相关开发者需保持高度警惕。

一、攻击背景：NPM 生态遭遇 “前所未有威胁”

NPM（Node Package Manager，节点包管理器）是全球最大的软件代码仓库，全球数百万开发者在构建网页应用、移动应用、企业级系统及其他 JavaScript 相关项目时，都会依赖该平台的代码包。

而当前，一场规模空前的供应链攻击正以惊人速度攻陷 NPM 包。攻击者利用 “自复制蠕虫” 通过这些代码包传播，不仅窃取用户密钥信息、泄露数据，还会利用窃取到的有效 NPM 令牌，进一步入侵更多代码包，形成 “连锁感染”。

二、攻击进展：从单一包扩散到多生态，500 余个包已 “沦陷”

这场攻击的警报最早在周一拉响 —— 当时安全人员发现，轻量级 JavaScript 色彩处理库tinycolor出现入侵痕迹。随后调查显示，受影响的代码包已超 40 个，且涉及多名代码维护者，并非单一团队管理的项目。

专注于供应链安全防护的网络安全公司 Socket，是首批追踪该攻击事件的机构之一。截至目前，该公司已统计出近 500 个遭入侵的 NPM 包，其他安全厂商的数据则显示，实际受影响的包数量可能更多。

此次攻击的 “重灾区” 包括：

CrowdStrike 相关包

多个下载量达数百万次的 CrowdStrike NPM 包被植入相同恶意代码；

移动与 Web 开发核心工具

超 30 个@nativescript-community系列核心库（用于跨平台应用开发）、Angular 生态关键包（如ngx-bootstrap、ngx-toastr）、40 余个@operato企业级包，以及数十个来自@ctrl和@art-ws开发框架的代码包。

三、开发者恐慌：“审计所有依赖根本不现实”

攻击事件已引发开发者群体的广泛焦虑。一位开发者在 Hacker News 论坛上直言：“我自己的项目也在用 NPM 包，但现在完全不知道该怎么保护自己。要审计我项目里的每一个依赖包，还要追溯这些依赖的‘依赖’，根本不现实。”

他进一步表示：“就算我有时间这么做，我也不是 TypeScript/JavaScript 专家 — 攻击者完全可以用混淆代码隐藏恶意逻辑，我根本分辨不出来。”

软件咨询公司 Loka 的高级后端工程师丹尼尔・佩雷拉（Daniel Pereira）也发出警告，称已有大量用户遭遇入侵。他在 LinkedIn 上提醒：“不要安装@ctrl/tinycolor@4.1.1及更高版本，也不要使用依赖该包的项目，建议暂时避免执行npm install命令。”

四、攻击机制：“沙虫（Shai-Halud）” 如何实现 “自我繁殖”？

安全研究人员将此次供应链攻击命名为 “沙虫（Shai-Halud）”—— 得名于攻击者部署的恶意工作流文件名，该名称源自弗兰克・赫伯特（Frank Herbert）科幻小说《沙丘》中的巨型沙虫。

这种恶意程序的 “自我繁殖” 逻辑如下：

• 当开发者下载并执行含恶意代码的包时，程序会通过工具TruffleHog扫描其设备，搜集云服务凭证、令牌及其他敏感信息；

• 验证搜集到的凭证有效性后，在开发者的代码仓库中创建未授权的 GitHub Actions 工作流；

• 将敏感数据泄露至公开的 GitHub 仓库（而非攻击者控制的服务器，增加了检测难度）；

• 同时更新代码包，植入恶意脚本bundle.js，并将开发者的私有代码公开。

据网络安全社区 Reddit 的一名安全从业者（网名 Advocatemack）透露：“目前已有 700 余个原本私有的代码仓库被强制公开。”

不过，Socket 公司表示，NPM 官方已在快速移除受影响的包，以遏制攻击扩散。

五、恶意代码运作细节：精准瞄准关键凭证

Socket 在分析中指出，此次攻击的恶意脚本采用 “本地扫描 + 特定服务探测” 结合的方式，重点 targeting 以下信息：

环境变量：如GITHUB_TOKEN（GitHub 令牌）、NPM_TOKEN（NPM 令牌）、AWS_ACCESS_KEY_ID（亚马逊云服务访问密钥 ID）、AWS_SECRET_ACCESS_KEY（亚马逊云服务密钥）；

凭证验证：通过 NPM 的whoami接口验证窃取的 NPM 令牌是否有效，若获取到 GitHub 令牌，则进一步调用 GitHub API；

云环境探测：尝试获取云构建代理中的短期有效凭证（这类凭证常被开发者忽视，却可能成为攻击突破口）。

六、紧急应对建议：四步降低风险

针对此次攻击，安全机构给出以下即时防护建议：

1. 清理恶意包

   卸载已确认遭入侵的 NPM 包，或将依赖版本 “锁定” 到已知安全的版本；

2. 审计运行环境

   检查曾安装过受影响包的环境（如 CI/CD 构建代理、开发者个人电脑），确认是否存在未授权的代码发布或凭证窃取行为；

3. 重置敏感凭证

   若设备曾运行过受影响包且存储有发布凭证，需立即重置 NPM 令牌及其他可能泄露的密钥；

4. 持续监控

   关注 NPM 官方及安全厂商的更新，及时掌握新增受影响包列表，避免误引入风险依赖。