npm 供应链投毒检测与响应：从 AntV 事件看维护者账号劫持的防护策略

开源软件供应链已成为现代应用开发的核心基础设施，但其安全边界却异常脆弱。2026 年 5 月 19 日，AntV 可视化生态遭遇大规模供应链攻击，攻击者通过劫持共享维护者账号 atool，向 @antv/g2、@antv/g6、echarts-for-react 等数十个流行 npm 包注入恶意代码。该事件波及数百万周下载量的核心库，暴露了开源生态中共享维护者身份带来的系统性风险。

攻击路径解析

此次攻击的入口是经典的钓鱼攻击。攻击者通过钓鱼手段获取了 atool 账号的 npm 发布令牌，随后利用该账号的广泛权限，在同一时间向多个包推送了恶意版本。值得注意的是，atool 作为共享维护者身份，其权限横跨整个 AntV 命名空间以及 echarts-for-react 等非 AntV 包，这意味着命名空间过滤无法限制攻击的波及范围。

恶意代码通过 npm 的 preinstall 钩子触发执行。当开发者执行 npm install 时，钩子会在构建开始前拉取一个约 11.7MB 的混淆 JavaScript payload。该 payload 采用重度混淆技术，静态分析工具难以在第一时间识别其恶意性质，只有在运行时才会暴露真实行为。

恶意代码行为剖析

攻击 payload 展现出高度专业化的信息收集能力。其目标清单涵盖开发环境中几乎所有敏感凭证：SSH 私钥、AWS 与 GCP 凭证文件、Kubernetes 配置、GitHub 和 npm 令牌、HashiCorp Vault 令牌，以及 AI 工具的配置文件。收集到的数据使用 RSA-OAEP-4096 和 AES-256-GCM 进行加密，随后通过三个冗余渠道外泄：Session Protocol 基础设施的 filev2.getsession.org、利用窃取令牌访问的 GitHub GraphQL API，以及 typosquat 域名 git-tanstack.com。

更具威胁性的是攻击的持久化机制。如果恶意代码获取到具有足够权限的 GitHub 令牌，它会在 Claude Code 和 VS Code 配置中插入钩子，安装名为 gh-token-monitor 的服务，并在仓库中植入恶意 GitHub Actions 工作流，将仓库密钥序列化发送到 api.masscan.cloud。这种设计使得即使初始感染被发现，攻击者仍能通过多种渠道维持对受害环境的访问。

攻击者还设置了 "死人开关"：npm 令牌描述中包含威胁性语句，暗示撤销该令牌将触发 rm -rf ~/ 命令删除用户主目录。这种心理战术旨在延缓受害者的响应速度。

检测策略与可落地参数

针对此类供应链攻击，团队需要建立多层次的检测机制。首先，在依赖审计层面，应建立基于时间戳的版本审查流程。任何在可疑日期（如此次攻击的 2026-05-19）发布的版本都应被视为高风险，需人工审查后方可使用。

具体检测参数包括：监控 package.json 和 lock 文件中是否存在异常的 preinstall、postinstall 脚本；检查依赖包的发布时间与版本号是否符合正常迭代规律；使用 npm audit 和第三方工具（如 Socket、Snyk）扫描已知恶意模式。

在 CI/CD 环境中，应实施网络 egress 监控。正常的构建过程不应需要访问 filev2.getsession.org、git-tanstack.com 或 api.masscan.cloud 等外部域名。任何此类出站连接都应触发告警并阻断构建。

文件完整性监控也是关键。攻击 payload 约 11.7MB，远大于正常 npm 包的辅助脚本体积。可在构建流程中加入包体积阈值检查，对超过 1MB 的脚本文件进行额外审查。

响应机制与操作清单

一旦发现潜在感染，应立即执行以下响应步骤：

第一阶段：隔离与遏制

• 立即终止所有可能受影响的 CI 流水线
• 隔离已安装可疑包的开发机和构建节点
• 阻止网络访问可疑外泄域名

第二阶段：凭证轮换

• 轮换所有可能暴露的凭证：SSH 密钥、云服务商 API 密钥、GitHub 个人访问令牌、npm 令牌
• 特别注意：轮换操作应离线执行，避免在可能受感染的环境中暴露新凭证

第三阶段：持久化清理

• 检查 ~/.vscode/settings.json 和 Claude Code 配置目录中的异常钩子
• 查找并移除 gh-token-monitor 服务
• 审查所有仓库的 .github/workflows 目录，删除未授权的工作流文件
• 检查 ~/.ssh/config 和 ~/.aws/credentials 等敏感文件是否被篡改

第四阶段：依赖修复

• 将受影响包回退至已知安全的版本（如 AntV 包应使用 2026-05-19 之前的版本）
• 更新 lock 文件并重新安装依赖
• 在隔离环境中验证新依赖的完整性

防护策略与架构建议

预防此类攻击需要从多个层面构建防御体系：

账号安全层面：强制所有维护者启用双因素认证（2FA），使用硬件安全密钥而非 SMS 作为第二因素。定期轮换 npm 发布令牌，并限制令牌的有效期和权限范围。

权限管理层面：遵循最小权限原则，避免使用共享维护者账号。每个包应有独立的发布权限配置，即使单个账号被攻破，也能限制攻击的波及范围。

依赖管理层面：锁定依赖版本，使用 package-lock.json 或 yarn.lock 确保可重现的构建。考虑使用私有 npm registry 或缓存代理，在引入外部包之前进行安全审查。

运行时防护层面：在 CI/CD 环境中实施网络分段，构建节点应限制对外部网络的访问。使用容器化构建环境，确保每次构建都在干净的环境中执行。部署运行时应用自我保护（RASP）工具，监控异常的进程行为和网络连接。

监控与告警层面：订阅 npm 安全公告和第三方供应链安全服务（如 Socket、Snyk）的实时告警。建立内部安全事件响应计划，明确供应链攻击场景下的职责分工和操作流程。

结语

AntV 供应链攻击事件再次证明，开源软件供应链的安全不能依赖单一环节的防护。从维护者账号的 2FA 保护，到 CI/CD 环境的网络隔离，再到依赖版本的锁定与审计，每个环节都需要建立相应的安全控制。对于开发团队而言，关键在于建立 "零信任" 心态：即使是来自知名维护者的流行包，也应经过适当的安全审查后再引入生产环境。

参考来源

• Prismor.dev: "AntV npm Packages Compromised via Hijacked Maintainer Account"
• OffSeq Threat Radar: "Malware Injected into 5 npm Packages After Maintainer Tokens Stolen in Phishing Attack"

security