# Axios 黑客事件：账户被入侵 3 小时如何影响 17.4 万个软件包
2026 年 3 月 30 日，一名攻击者入侵了 Axios 维护者的账户，发布了该库的恶意版本，影响了大约 17.4 万个依赖包。这次仅持续 3 小时的攻击，是由于依赖管理流程和安全工具中的盲点所致。让我们来剖析事件经过，并了解如何保护自己。
攻击机制：从账户入侵到 RAT
事件起因是 jasonsaayman 账户（Axios 首席维护者）的电子邮件被更改为 [email protected]，并从可信的 OIDC 管道切换到直接 CLI-publish。这些变更被 Elastic Security Labs 通过供应链监控自动检测到。恶意版本 Axios 1.14.1（最新标签）和 0.30.4（旧版标签）包含了一个可疑依赖 plain-crypto-js。
攻击者采用了双阶段方案：
- [email protected] —— 此前发布的合法版本，用于制造历史记录
- [email protected] —— 恶意版本，带有 postinstall 钩子，从 sfrclak[.]com:8000 服务器加载 RAT
攻击的一个关键特点是没有修改 Axios 源代码。攻击者只是将恶意包添加到依赖列表中。RAT 支持跨平台，在与 C2 服务器建立连接后，可为 macOS、Windows 和 Linux 提供完全远程访问。
为什么标准安全工具失效
大多数 CI/CD 管道未能检测到威胁，原因有几点。NPM Audit 将包与 CVE 数据库比对，结果显示干净，因为新版本尚未被记录为已知漏洞。该工具本质上无法检测通过账户入侵的新鲜攻击——它仅适用于已知 CVE。
许多团队流程中的一个关键失误是没有固定依赖版本。使用 ^1.x.x 时，管道会自动解析到最新版，从而在 3 小时窗口期拉取了恶意版本。根据 OpenSSF Scorecard 2024 数据，不到 20% 的项目使用固定依赖哈希。传递依赖（仅在构建时需要的包）不在检查范围内，尽管它们同样构成威胁。
新的供应链安全规则
Axios 事件暴露了传统安全模型的系统性缺陷。过去，责任分属于团队负责人（模块选择）、DevOps（交付）和安全团队（SAST/DAST）。但没有人负责监控维护者账户的完整性。对签名包的信任绑定到特定账户，而该账户可能被入侵。
漏洞规模之大，可归因于 Axios 在生态中的主导地位：每周 1 亿次下载，17.4 万个依赖包。一个典型的 Node.js 项目有 40–60 个直接依赖，每个还会拉取 5–7 个传递依赖。这意味着超过 200 个包，每个都有独立的账户所有者，其安全性往往被忽视。
AI 在威胁升级中的作用
现代攻击往往有国家支持并使用 AI。在本例中，归因指向朝鲜威胁行为者（Google Cloud Threat Intelligence）。神经网络加速了开源代码中的漏洞狩猎：过去需要数小时的任务如今只需几分钟。
根据 Google Project Zero（2023）的数据，从漏洞发现到修补的中位时间为 25 天。AI 让攻击者搜索漏洞的速度快于安全团队的增长速度。开源中未被检测的漏洞数量达数百万，为攻击提供了广阔战场。
有效的防护措施
此次攻击并非被标准安全工具阻止，而是 Elastic Security Labs 的行为监控发挥了作用。要防止类似事件，在 CI/CD 中实施以下措施：
- 固定版本 — 使用
npm install --frozen-lockfile并提交 package-lock.json - 签名检查 —
npm audit signatures验证 SLSA 来源 - 依赖 SAST — 对已安装包进行静态分析
- 自动警报 — 使用 Dependabot 跟踪 CVE
- 元监控 — 分析邮件变更、发布方法和依赖历史
大型公司已在 DevSecOps 中采用这些实践。小型项目占受影响包的大多数，往往因复杂性和资源不足而忽略它们。
关键要点
- 签名至关重要 — 检查加密签名（
npm audit signatures）能立即检测从 OIDC 到 CLI 的发布方法切换。 - 传递依赖构成威胁 — 未进入生产环境的包仍可在构建阶段执行恶意代码。
- 行为分析胜过 CVE 检查 — 对于新鲜攻击，监控元数据（邮件、发布历史）比漏洞数据库更重要。
- 版本固定必不可少 — 放弃 ^1.x.x 可防止自动拉取恶意最新版。
Axios 事件标志着一个转折点：安全边界如今包括第三方代码和维护者账户。那些不调整流程的人将持续易受针对性供应链攻击。响应时间已缩短至数小时——防护必须自动化并覆盖所有阶段。
— Editorial Team
暂无评论。