PolinRider：npm 供应链攻击用区块链做 C2，10 个包 12 个版本被投毒

2026 年 11 月 4 日，Sonatype 确认了一起被命名为 PolinRider 的 npm 供应链攻击，编号 sonatype-2026-010515，评级为高危。

1. 攻击规模

影响面的关键在于传递依赖：在暴露窗口内拉取过这些版本的项目，无论直接依赖还是深几层的间接依赖，都会连同正常代码一起装上 PolinRider 加载器。

2. 载荷的两个特征

两阶段设计。隐藏代码先解析出命令与控制服务器地址，再回连。这一步是恶意软件的传统做法，新鲜的是地址来源。

用区块链当配置分发。C2 地址从发布到以太坊上的数据里读取，而不是硬编码在代码里，也不是从常见的一次性域名获取。好处是抗下架：域名可以被封、IP 可以被拉黑，但链上数据改不了、删不掉。

这种手法在真实攻击里出现得越来越多，因为它同时解决了两个问题——抗溯源、抗清除。

3. 为什么 npm 生态特别容易中招

三个结构性原因：包数量巨大且信任默认传递；安装脚本（postinstall 等）默认执行；一个被控维护者账号能一次性污染多个包。

这次是 10 个包，不是 1 个。攻击者显然优先拿"一批包的控制权"，而不是逐个投毒。

4. 该怎么处置

如果 CI 或开发机在暴露窗口内安装过这些版本，按"主机已被入侵"处理：轮换所有能从该环境读到的凭据（npm token、云密钥、CI secrets），检查 postinstall 的异常网络连接，再用锁文件固定干净版本重新拉依赖。

长期做法是把依赖安装纳入可控环节：私有 registry 代理、锁文件与完整性校验、安装脚本白名单，以及定期的依赖审计。

小结

PolinRider 的教训不是"又一起供应链攻击"，而是 C2 的分发方式在进化：区块链让恶意配置变得不可删除，传统"封域名、拉黑 IP"的处置链条在这里失效。

对普通项目的现实建议只有一条：把 npm install 视为执行陌生代码。锁文件、私有源、脚本白名单，这三样做到任意两样，就能挡掉这一整类攻击的大部分场景。

数据来源与检索时间

检索时间 2026-11-10。

核验说明

• 规模数字、时间、编号与载荷机制均来自上述分析文章；区块链承载 C2 的具体链上地址未在文中给出，也不建议读者自行探测。
• 未做：没有下载或分析样本，没有在隔离环境复现载荷行为；文中处置建议是通用做法，不是针对该样本的验证结论。