NPM 包劫持是一种软件供应链攻击，它将对软件包的信任转化为攻击途径。如果攻击者能够控制发布该软件包的账户，则无需修改仓库中的代码。
这正是可信的 npm 包成为如此强大的攻击面的原因。一旦维护者账户遭到入侵，所有安装了受影响包的项目都可能在例行依赖项更新过程中暴露在风险之中。2026 年 3 月的 Axios 事件表明，一个遭到入侵的 npm 账户，即使未对 axios 源代码进行任何可见的修改，也能使每周超过 1 亿次的下载面临风险。
了解 npm 包劫持的运作原理，有助于安全团队构建针对实际攻击路径的防护措施，而非仅关注大多数团队通常审查的源文件。
Axios npm 攻击事件始末
Axios npm 攻击事件是一起维护者账户被劫持的事件，导致一个受信任的软件包变成了恶意软件的传播载体。攻击者入侵了 Axios 主要维护者的 npm 账户，将注册邮箱更改为攻击者控制的地址，并阻止了合法维护者登录。
此次攻击经过精心策划。在有效载荷被激活前约18小时，攻击者发布了一个诱饵包，以此建立发布记录，避免立即引起怀疑。随后，在约39分钟内，攻击者推送了两个恶意版本：针对现代发布分支的axios 1.14.1，以及针对旧版分支的axios 0.30.4。
这两个发布分支被同时作为攻击目标，以最大限度地扩大影响范围。这一选择增加了当前环境和旧环境通过标准更新机制拉取受污染软件包的可能性。
package.json 文件中的一行代码如何成为攻击载体
在 npm 供应链攻击中，package.json 中一个依赖项的变更就可能成为整个攻击路径。在 Axios 事件中，由于恶意行为是通过一个新依赖项引入的，因此无需修改任何 Axios 源文件。
该依赖项是通过 npm 的 postinstall 钩子执行的。一旦开发者的工作站、CI/CD 管道或构建系统运行了 npm install 命令，该恶意包就会联系攻击者控制的服务器，获取针对特定操作系统的有效载荷，并开始执行。
这些有效载荷针对 macOS、Windows 和 Linux 系统进行了准备。该攻击在设计上具有跨平台特性。运行后，该释放器会清除自身痕迹，并将真实的 package.json 文件替换为伪造版本，这使得后续的取证分析变得极为困难。
为什么传统的代码审查未能发现Axios攻击
传统的代码审查旨在检查代码库内的源代码变更，但此次攻击的漏洞并不存在于 Axios 的源代码中。Axios 此次遭受的攻击并未依赖于代码库中的可见变更，因为恶意逻辑存在于一个独立的依赖项中，而非 Axios 的源代码中。
这种差异至关重要。审查人员查看包更新时，除了在 package.json 中看到一条新的依赖项外，几乎不会发现其他异常。只有在解析并安装该依赖项后，实际的恶意行为才会显现。
这就是为什么仅靠基于diff的代码审查很难发现受信任包攻击。尽管该包看起来仍足够合法，能够通过常规开发工作流，但其攻击路径却位于大多数团队检查的源文件之外。
为什么爆炸半径就是弹药包所触及的范围
受感染的 npm 包所造成的破坏范围并非该包本身，而是该包所涉及的一切。
对于大多数组织而言，这包括具有高权限的持续集成/持续交付（CI/CD）管道、包含 SSH 密钥和云令牌的开发者端点、对构建产物仓库具有写入权限的构建服务器，以及连接到生产系统的部署工具。恶意包无需一直留在依赖项树中即可造成危害，它只需要一个受信任的执行点即可。
正因如此，Axios 事件的重要性远不止于 JavaScript 包管理。基于 postinstall 的安全漏洞可能将一次普通的安装操作转化为凭证窃取、横向移动或对下游基础设施的访问。
Axios 攻击暴露出的结构性缺陷
Axios 事件暴露了现代软件开发环境中普遍存在的结构性缺陷。这些并非罕见的特例，而是许多组织中的普遍假设。
信任软件包维护者的身份
npm 包的信任关系通常与发布该包的维护者账户绑定。如果该账户被盗或遭遇网络钓鱼攻击，攻击者将获得与合法维护者相同的发布权限。
浮动依赖版本
采用浮动版本或松散固定版本的发布策略会增加遭受恶意版本攻击的风险。新发布的受感染版本可能在未经刻意批准的情况下自动进入系统环境。
未受监控的安装后脚本
npm 的 postinstall 脚本可以以安装进程的权限执行任意代码。许多组织在运行生命周期脚本之前并未对其进行检查或限制。
运行时可见性受限的 CI/CD 管道
CI/CD 管道通常拥有对内部系统、构建基础设施和云环境的广泛访问权限。这些管道通常默认被视为可信，且在安装时极少受到针对恶意软件包行为的监控。
未受全面安全保护的开发者端点
开发人员的工作机上存储着高价值资产，包括 SSH 密钥、云凭证和企业令牌。开发人员的工作节点也是常见的攻击目标，因为与生产系统相比，它们的可视性较低，且运行时控制措施较少。
不使用快速轮换触发器的凭据存储
软件供应链攻击往往会导致凭证泄露事件。许多团队至今仍未建立可靠的工作流程，以识别可能已泄露的机密信息并立即进行轮换。
哪些安全控制措施本可以改变结果
如果采取三类安全控制措施，本可以大幅减轻Axios遭受攻击的影响。每项控制措施针对攻击链中的不同环节：包执行、凭证泄露以及依赖项可见性。
1. 安装前的软件包级恶意软件扫描
包级恶意软件扫描有助于在恶意依赖项执行前将其拦截。这一点在 npm 攻击中尤为重要，因为 postinstall 钩子会在安装过程中运行，一旦包被拉取，就几乎没有时间进行人工审查。
在安装前对软件包、依赖项和生命周期脚本进行扫描，可以在软件包到达开发人员终端或 CI/CD 环境之前，识别出已知的恶意软件、可疑行为、漏洞以及硬编码的密钥。
MetaDefender Software Supply Chain 是OPSWAT软件供应链安全解决方案，用于验证软件组件、供应商和构建管道。该方案采用多引擎威胁检测技术，包括利用 Metascan 跨 30 多个杀毒引擎进行多重扫描，在软件包进入开发生命周期之前，对其进行恶意软件、漏洞和硬编码密钥的检测。
2. 通过轮换触发器实现主动的密钥管理
主动的密钥管理能降低成功入侵的危害。一旦发现可疑包，团队需要一套响应流程，将本地凭据、SSH密钥、令牌和管道密钥视为可能已泄露，并迅速进行轮换。
硬编码密钥检测同样旨在实现这一目标。恶意软件包虽可从内存或磁盘窃取密钥，但代码或依赖项中已暴露的密钥则构成了另一层本可避免的风险。
3.Supply Chain 与依赖关系监控
供应链可视性有助于团队在意外的包变更演变为下游问题之前及时发现这些变更。安全团队需要了解已安装的包有哪些、哪些版本已被锁定、出现了哪些新的依赖项，以及这些组件正在何处运行。
如果没有对依赖项的可见性和监控，系统遭到入侵的最初迹象可能是在原始安装事件发生很久之后才出现的凭证滥用或基础设施误用。
深入了解Software Supply Chain
Software 安全取决于在执行前检查软件包、监控新依赖项，以及在软件包遭到入侵后降低凭证泄露的风险。
常见问题
什么是 npm 供应链攻击？
npm 供应链攻击是指在正常的软件开发过程中，通过 npm 生态系统植入恶意代码的行为。攻击者通常通过入侵维护者账户、发布欺骗性包，或在开发人员和 CI/CD 系统自动安装的依赖项中植入恶意行为来实现这一目的。
攻击者是如何攻破 Axios npm 包的？
攻击者入侵了 axios 主要维护者的 npm 账户，并利用该账户的发布权限，在 1.x 和 0.x 两个发布分支上发布了恶意版本。攻击者还将账户邮箱更改为由其控制的地址，从而得以持续掌控该软件包。
Axios 攻击中的恶意软件做了什么？
在Axios攻击中，恶意软件利用了一个安装后钩子，在执行npm install时触发。该钩子会联系攻击者控制的服务器，下载适用于macOS、Windows或Linux的远程访问木马，将其启动，然后通过用伪造内容替换包元数据来试图抹去痕迹。
为什么代码审查没有发现针对 Axios 的供应链攻击？
代码审查未能发现该Axios攻击，因为恶意逻辑并非源自Axios的源代码。从代码库层面看，唯一可见的变更仅是package.json文件中新增的依赖项，而实际的恶意软件则是通过源代码审查常规范围之外的外部包引入的。
组织如何在安装前检测恶意 npm 包？
组织可以通过在执行前扫描包内容、依赖关系树和生命周期脚本，在安装前检测出恶意的 npm 包。有效的管控措施应结合恶意软件扫描、依赖关系分析、策略执行以及 CI/CD 集成，从而在可疑包进入开发或构建环境之前将其拦截。
版本锁定能否防止 npm 供应链攻击？
版本锁定通过限制自动升级，可降低因新发布的恶意版本带来的风险。但版本锁定并不能消除供应链风险，因为被锁定的版本可能早已遭到破坏，或者仍存在其他信任问题。版本锁定与完整性验证、软件包检查及运行时控制相结合时，效果最佳。
