史上最大规模 NPM 供应链攻击 “雷声大雨点小”，背后警示值得警惕

图片

威胁攻击者通过钓鱼手段攻陷开发者 Qix 的 NPM 账户，篡改 18 个热门开源包并植入恶意代码 — 这些包的周下载量超 20 亿次。尽管此次攻击规模堪称历史之最，但其实际造成的破坏远低于预期，却为全球开源生态安全敲响了警钟。

01 一场本可能引发 “灾难” 的攻击：事件始末

2025 年 9 月 8 日清晨，一场针对开源生态的供应链攻击悄然启动。威胁攻击者通过钓鱼攻击成功入侵知名开发者 Qix 的 NPM（Node 包管理器）账户，随后利用该权限发布了 18 个热门开源包的 “毒版本”。

这些受影响的包均为前端开发领域的 “基础设施级” 工具，包括用于终端样式渲染的ansi-styles、调试工具debug、颜色处理库chalk以及终端颜色支持检测工具supports-color，其总周下载量累计超过 20 亿次，覆盖全球数百万开发者与企业系统。

攻击者在篡改后的包中植入了加密货币窃取恶意软件，在约两小时的 “窗口期” 内，所有新下载这些包的用户都会感染该恶意软件。幸运的是，包的维护者 Qix 及时发现异常，迅速下架了受感染版本，避免了攻击范围的进一步扩大。

尽管此次事件最初引发了对 “Log4j 级灾难” 的担忧（2021 年 Log4j 漏洞曾导致全球数十亿设备面临风险），但截至目前，实际影响远低于预期。安全倡导组织 Security Alliance 在博客中指出，攻击者从此次攻击中仅窃取了约 5 美分的以太坊，以及 20 美元的某 “meme币”（该币种 24 小时交易量仅 588 美元），经济收益几乎可以忽略不计。

02 攻击 “失效” 的核心原因：能力不足还是侥幸？

为何覆盖超 20 亿次下载量的攻击会 “收效甚微”？行业专家从技术与攻击者能力层面给出了关键解读：

1. 攻击者技术水平 “业余”，恶意代码易被检测

安全研究员弗洛里安・罗斯在社交平台 X 上直言，此次攻击暴露了攻击者的能力短板。他指出，大多数企业都运行着基于 React 或 Angular 的前端应用，理论上攻击者有机会在数千家组织的数百万系统中执行代码，但他们最终选择的恶意软件 “加密混淆手法极其业余”，很快就被基础检测规则识别，且仅两小时就被完全修复。

“所有人都该意识到这次有多危险 — 如果换成真正具备专业能力的攻击者，后果不堪设想。” 罗斯强调。

2. 维护者响应迅速且透明，阻断攻击扩散

Checkmarx Zero 安全研究倡导者达伦・迈耶认为，尽管攻击者的前期准备（如高质量钓鱼攻击、预制备恶意包）体现了一定组织性，但 Qix 的快速响应成为关键转折点。Qix 在发现问题后第一时间下架恶意版本，并以透明方式公开事件进展，帮助开发者和企业及时排查风险，大幅降低了下游影响。

迈耶同时提醒：“这起事件仍带有‘熟练、有组织、有明确动机’的攻击者特征，且可能是一场持续的攻击。开发者社区能幸免于难，更多是因为运气，而非必然。”

03 开源生态的 “脆弱性” 暴露：单一维护者风险成隐患

尽管此次攻击未造成重大损失，但它再次揭示了现代开源生态的核心脆弱性 —“单一个人维护关键基础设施” 的风险。

JFrog 安全部门首席技术官阿萨夫・卡拉斯在接受采访时指出，此次事件是 “历史上最大规模的 NPM 供应链攻击”，其背后反映的问题比攻击本身更值得警惕：“现代 JavaScript 生态系统极其脆弱，半数代码库依赖于由单一开发者维护的‘单行工具库’。一旦这些核心维护者的账户被攻陷，整个生态都会面临风险。”

Black Duck 高级安全解决方案经理迈克・麦圭尔进一步补充，此次攻击者使用的恶意软件虽 “收益微薄”，但其技术设计存在多层风险，尤其是 “在用户不知情的情况下篡改 API 调用、重定向加密货币交易” 的逻辑，若应用在金融、支付等核心场景，可能引发严重数据泄露与资金损失。

04 企业与开发者必看：如何排查风险并加固防御？

针对此次事件暴露的问题，安全厂商与专家给出了具体的风险排查与防御建议，帮助组织避免类似威胁：

1. 立即排查：确认是否感染恶意版本

安全厂商 Wiz 在博客中建议，团队应优先通过以下方式排查风险：

• 搜索项目的lockfiles（如package-lock.json）与包仓库，确认是否存在受感染的包版本；
• 检查系统遥测数据与用户反馈，重点关注 “签名流程异常失败”“ERC-20 代币授权中陌生支出地址”“转账被重定向” 等迹象；
• 对恶意包传播窗口期（9 月 8 日上午）活跃的用户进行链上交易审查；
• 扫描 JavaScript 资产，排查是否存在可疑的代码混淆痕迹。

2. 长期防御：构建供应链安全 “基础防线”

达伦・迈耶与 Sophos 托管检测响应总监保罗・贾拉米洛均强调，依赖开源包的组织（如今几乎所有企业都是）必须建立供应链安全基础体系，具体包括：

• 维护私有包仓库，避免直接使用公共仓库的 “最新版本”；
• 部署供应链安全工具，实时监控包的版本变化与异常修改，建立 “可信包清单”；
• 禁用构建环境的 “自动更新依赖” 功能，所有包版本更新需经过人工审核与安全测试；
• 建立受影响包的 “黑名单”，并每日更新（包括此次受牵连的 DuckDB 等包），强制覆盖为已知安全版本；
• 使用端点安全工具，在攻击发生时快速限制影响范围，避免恶意代码横向扩散。

05 开源安全需 “集体防御”，而非依赖 “侥幸”

此次 NPM 供应链攻击虽以 “雷声大雨点小” 收尾，但它为全球开源生态敲响了警钟。随着开发者与企业对开源工具的依赖程度不断加深，“单一维护者风险”“供应链劫持” 等威胁将持续存在。

正如阿萨夫・卡拉斯所言：“此次事件的影响虽小，但它暴露的脆弱性是真实存在的。开源安全不是某一个人的责任，而是需要企业、开发者、安全厂商共同构建的‘集体防御体系’— 只有提前加固防线，才能避免下一次‘侥幸’变成‘灾难’。”