币圈搬运工 
新型 NPM 供应链攻击波及 ENS 与加密生态：开发者需高度警惕
近日，一场大规模的 JavaScript 供应链攻击席卷了 npm（Node Package Manager）生态系统，波及数百个软件包，其中至少有 10 个被广泛用于加密货币领域。据网络安全公司 Aikido Security 的研究人员 Charlie Eriksen 披露，此次攻击使用了一种名为“Shai Hulud”的自复制蠕虫恶意软件，已感染超过 400 个 npm 包。Eriksen 强调，他已对每个检测结果进行了人工验证，以避免误报。
值得注意的是，多个与以太坊域名服务（ENS）相关的高下载量包已被确认感染，包括每周下载量近 3.6 万次的 content-hash 和超 3.75 万次的 address-encoder。这些包不仅自身用户众多，还被大量其他项目依赖，潜在影响范围极广。
Shai Hulud 攻击机制解析
与此前直接盗取加密资产的攻击不同，Shai Hulud 是一种通用型凭证窃取恶意软件。它并不专门针对钱包，而是扫描开发环境中的各类“机密信息”（secrets），如 API 密钥、SSH 凭据、数据库密码等。如果环境中恰好存有加密钱包私钥，也会被当作普通密钥一并窃取。
自动传播与隐蔽性强
该蠕虫具备自主传播能力：一旦某个开发者安装了受感染的 npm 包，恶意代码便会在其本地或 CI/CD 环境中执行，进而尝试访问 Git 凭据、npm token 或云服务密钥，并利用这些权限创建新仓库或污染更多包，形成链式反应。
与早期攻击的关联
此次事件并非孤立。早在 2025 年 9 月初，曾发生过史上规模最大的 npm 攻击，黑客借此窃取价值 5000 万美元的加密资产。AWS 指出，Shai Hulud 蠕虫正是在那次攻击后约一周开始自主扩散，显示出攻击者策略从“定向盗窃”向“广域渗透”的演变。
受影响的关键加密项目
尽管攻击波及广泛，但加密生态因其高价值成为重点目标。以下是已被确认感染的部分关键包及其影响规模：
| 包名称 | 周下载量 | 依赖项目数 | 用途 |
|---|---|---|---|
| content-hash | ~36,000 | 91 | ENS 内容哈希处理 |
| address-encoder | ~37,500 | — | 多链地址编码 |
| ensjs | ~30,000 | — | ENS JavaScript SDK |
| crypto-addr-codec | ~35,000 | — | 通用加密地址编解码 |
| ethereum-ens | ~12,650 | — | 以太坊 ENS 工具库 |
ENS 团队已在收到警告后紧急响应，但鉴于这些包已被深度集成于 DApp、钱包和基础设施中，修复和审计工作仍需时间。
非加密领域同样遭殃，影响远超预期
此次攻击不仅限于加密圈。企业自动化平台 Zapier 的多个 npm 包也被感染，其中一个周下载量超 4 万。更令人担忧的是，部分通用工具包的周下载量高达 **150 万次以上**，意味着潜在受害者可能遍布 Web 开发、SaaS、金融科技等多个行业。
- 安全公司 Wiz 报告称，已发现 **25,000 多个受影响仓库**，涉及约 350 名独立用户。
- 过去几小时内，平均每 30 分钟就有 **1,000 个新仓库被污染**。
- Eriksen 在 X 平台直言：“这次攻击的规模之大，会让上一次看起来微不足道。”
由于 npm 生态高度依赖第三方包，一个看似无害的依赖项可能成为整个系统的“特洛伊木马”。任何使用 npm 的团队都应立即审查依赖树，尤其是近期更新过的包。
常见问题解答
如何快速判断我的项目是否使用了受感染的包？
可使用 npm ls 命令列出完整依赖树，并对照 Aikido Security 公布的感染包清单（如 GitHub 或 X 上发布的列表）。也可借助 Snyk、Socket.dev 或 npm audit 等工具进行自动扫描。
如果只是开发环境安装了恶意包，生产环境是否安全？
不一定。若开发机存有 Git 凭据、云服务密钥或钱包助记词，恶意软件可能已窃取这些信息并用于后续攻击。建议立即轮换所有相关密钥，并检查私有仓库是否被意外公开。
ENS 用户需要更换域名或重置钱包吗？
目前没有证据表明 ENS 域名本身被篡改或私钥被直接泄露。但若你曾在本地开发环境中使用过受影响的 ENS 包并存储过私钥，应视为高风险，建议迁移资产至新钱包。
为什么攻击者不直接偷币，而要传播蠕虫？
Shai Hulud 采用“广撒网”策略：通过窃取开发者的基础设施权限，攻击者可长期潜伏、横向移动，甚至控制更多项目发布渠道，实现更大规模、更持久的收益，远比单次盗币更危险。
未来如何防范此类供应链攻击？
建议采取最小权限原则（如限制 npm token 权限）、启用双因素认证、使用依赖锁定文件（package-lock.json）、定期审计间接依赖，并考虑引入软件物料清单（SBOM）工具监控第三方组件风险。