---
title: "PolinRider：npm 供应链攻击用区块链做 C2，10 个包 12 个版本被投毒"
date: 2026-11-10
slug: npm-polinrider-supply-chain
canonical: https://kernelranch.com/blog/2026/11/npm-polinrider-supply-chain
markdown_url: https://kernelranch.com/blog/2026/11/npm-polinrider-supply-chain.md
tags: ["npm", "supply-chain", "security", "malware"]
---2026 年 11 月 4 日，Sonatype 确认了一起被命名为 PolinRider 的 npm 供应链攻击，编号 sonatype-2026-010515，评级为高危。

## 1. 攻击规模

| 项目 | 数值 |
|---|---|
| 被控制的 npm 包 | 10 个 |
| 投毒的发布版本 | 12 个 |
| 发现与确认 | Sonatype，2026-11-04 |
| 编号 | sonatype-2026-010515 |
| 评级 | 高危 |

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

| 来源 | URL | 对应数据 |
|---|---|---|
| Defend Edge《PolinRider: npm Supply Chain Attacks Meet Blockchain C2》 | https://www.defendedge.com/polinrider-npm-supply-chain-attacks-blockchain-c2/ | 10 个包、12 个投毒版本、两阶段载荷、用以太坊承载 C2 地址、Sonatype 于 2026-11-04 确认、编号 sonatype-2026-010515、评级高危 |

## 核验说明

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