8.0
热点
AI SCORE
技术实践2026-08-05 04:30
Keyv 供应链攻击关键信息：Shai-Hulud 行动
dev.to · AI#供应链安全#npm#Keyv
Editor brief · 编辑速览
Node.js 知名键值抽象库 Keyv 及其多个存储适配器（Redis/MongoDB/SQLite 等）被植入恶意代码，可窃取环境变量和密钥，已存在 typosquatting 和维护者账户被控两种攻击路径。
Shai-Hulud 供应链攻击波及 Keyv 及多个相关 npm 包，在其中注入了恶意代码，可窃取受影响 Node.js 应用的环境变量和敏感信息。若你使用了 Keyv 或其任何适配器包，需立即审计依赖项。本文将详细剖析事件经过、受影响包列表，以及你今天需要采取的具体措施。
Keyv 是 Node.js 生态中广泛使用的键值存储抽象库，本次与多个配套包一同遭受了协同供应链攻击，该攻击被命名为 Shai-Hulud。
恶意版本被发布至 npm registry，目标直指依赖 Keyv 进行缓存和存储抽象的开发者。
攻击向量涉及 typosquatting（拼写错误劫持）和维护者账号被黑，而非源代码本身的漏洞。
受影响的包包括 Keyv 核心包及多个存储适配器（Redis、MongoDB、SQLite 等）。
需立即行动：审计你的 package-lock.json、轮换所有密钥、锁定至已验证的安全版本。
此次事件是教科书级别的案例，说明软件供应链安全应在 DevSecOps 工作流中占据一席之地。
Shai-Hulud 攻击——以 Frank Herbert《沙丘》中巨型沙虫命名，或许是在暗指该攻击地下渗透、隧道穿行的特性——是一场针对 npm 生态的持续性协同攻击。安全研究员于 2026 年中首次标记该攻击，此前在 Keyv（Node.js 生态下载量最高的键值存储库之一）的发布版本中检测到了异常行为。
从本质上看，此次攻击遵循了一种在开源生态中已变得令人不安的常见模式：入侵维护者账号，推送表面看起来合法的恶意包版本。注入的有效载荷非常隐蔽——它不会破坏功能，而这恰恰是其危险之处。应用在恶意代码静默收割环境变量、API 密钥、数据库凭据和其他敏感数据的同时，一切正常运行如常。
[INTERNAL_LINK: npm supply chain attacks overview]
Keyv 并非小众工具，每周下载量达数千万次，是大量 Node.js 应用、框架和工具的存储抽象层。许多开发者间接使用它——它是依赖的依赖。值得注意的是，其下游使用者包括热门的缓存中间件、会话管理库，甚至一些知名 API 框架。
该库的核心包加上一系列存储适配器的架构，给攻击者提供了多个攻击面。仅入侵一个适配器包，就可能影响生态圈的很大一块。
根据 npm 安全团队和独立研究员的披露，以下包在 Shai-Hulud 攻击中发布了恶意版本：
重要提示：受入侵版本的确切版本号，应通过 npm 官方安全公告和 Keyv GitHub 仓库安全通知进行核实，因为受影响的范围在撰写本文时仍在全面枚举中。采取行动前务必交叉参照官方来源。
对注入代码进行逆向工程的研究员发现了一个多阶段有效载荷：
环境变量窃取：恶意代码在包初始化时读取 process.env 并序列化所有环境变量。
出站信标：数据经编码后通过 HTTPS POST 请求发送到伪装成遥测端点的攻击者控制域名。
持久化尝试：部分变体中，代码尝试向项目的 node_modules/.bin 目录写入一个小加载器。
混淆：有效载荷使用 base64 编码和字符串拼接以避免简单的静态分析。
这里的 sophistication 值得注意。这不是脚本小子（script kiddie）的操作——攻击者显然清楚如何躲避基本 CI/CD 安全检查的雷达。
理解攻击机制有助于防范未来类似事件。
安全研究员认为初始向量是针对 Keyv 生态相关 npm 维护者账号的凭证填充（credential stuffing）或钓鱼攻击。一旦攻击者获得包的发布权限，他们就拥有了一条通往每个安装或更新该包的项目直接管道。
攻击者发布了通过粗略审查的新补丁或小版本——changelog 看似合理，版本号只是小幅度提升。这利用了 npm 生态中的一个基本信任假设：来自已知可信包的新版本是安全的。
由于 Keyv 及其适配器使用如此广泛，恶意版本在发布后数小时内就被拉入全球范围内的 CI/CD 流水线、Docker 构建和开发环境。开发者运行 npm install 或 npm update 而未锁定版本时，会在不知不觉中受影响。
任何初始化了被入侵包的运行环境——考虑到 Keyv 作为缓存层的角色，这通常发生在应用启动时——其环境变量都会被静默窃取。
[INTERNAL_LINK: how to secure npm dependencies]
如果你使用 Keyv 或任何适配器包，在完成以下步骤之前，请将此视为活跃事件。
运行以下命令识别你正在运行的版本：
npm list keyv
npm list @keyv/redis
npm list @keyv/mongo
npm list @keyv/sqlite
npm list @keyv/postgres
将输出与官方安全公告交叉参照。不要只检查直接依赖项——也要检查传递依赖项。
要进行更全面的审计，Socket Security 等工具提供了深度供应链分析，超出了 npm audit 的能力范围。Socket 主动监控包的行为异常，不仅限于已知 CVE。
假设已被入侵。如果你的应用使用了受影响版本的包——哪怕只是短暂的——你必须将与环境中存在的所有密钥视为可能已被窃取：
数据库凭据——立即轮换。
API 密钥（第三方服务、支付处理器等）——重新生成所有。
JWT 密钥和会话密钥——轮换并使现有会话失效。
云服务商凭据（AWS、GCP、Azure）——轮换并审计是否有未授权访问。
Webhook 密钥——重新生成。
这不是可选项。轮换密钥的成本远低于数据泄露的代价。
一旦确认哪些版本是干净的（通过官方公告），在 package.json 中显式锁定依赖项：
{
"dependencies": {
"keyv": "4.5.4",
"@keyv/redis": "2.8.0"
}
}
在 CI/CD 流水线中使用 npm ci 而非 npm install，以强制执行 lockfile。
考虑启用 npm provenance 并在可用时检查包签名。npm registry 现在支持通过可信 CI 系统发布的包的 provenance 证明。
检查你的云提供商审计日志、应用日志和网络出口日志，查找：
到陌生域的异常出站 HTTPS 连接。
环境变量访问的峰值。
到已知 Shai-Hulud C2 域的任何连接（查看威胁情报源获取当前列表）。
此次事件敲响了警钟。以下是值得集成到你工作流的工具：
Socket Security — 超越 CVE 扫描，检测包中的恶意行为模式。与此类攻击直接相关。客观评价：捕获供应链攻击能力出色，但需要集成工作，对于免费层以外的团队有成本考量。
Socket Security — 超越 CVE 扫描，检测包中的恶意行为模式。与此类攻击直接相关。客观评价：捕获供应链攻击能力出色，但需要集成工作，对于免费层以外的团队有成本考量。
Snyk — 广泛的漏洞扫描，IDE 集成良好。客观评价：在已知 CVE 方面强大，但对 Shai-Hulud 等零日供应链攻击效果较弱，但仍是有价值的基线层。
Snyk — 广泛的漏洞扫描，IDE 集成良好。客观评价：在已知 CVE 方面强大，但对 Shai-Hulud 等零日供应链攻击效果较弱，但仍是有价值的基线层。
Dependabot — GitHub 内置自动化依赖更新和安全警报。客观评价：免费且易于启用，但不能捕获行为异常。作为地板而非天花板来使用。
Dependabot — GitHub 内置自动化依赖更新和安全警报。客观评价：免费且易于启用，但不能捕获行为异常。作为地板而非天花板来使用。
如果此次事件暴露了你在密钥管理实践方面的差距，考虑：
HashiCorp Vault — 企业级密钥管理。客观评价：功能强大但运维复杂。对于处理敏感工作负载的团队值得投入。
Doppler — 开发者友好的密钥管理，CI/CD 集成出色。客观评价：对于小型团队比 Vault 更容易采用。
LockfileCheck — 审计 lockfile 中的可疑修改。客观评价：小众但确实有助于捕获 lockfile 投毒攻击。
针对 Keyv 及相关包的 Shai-Hulud 攻击并非孤立事件。它遵循了一种成熟的模式：
SolarWinds（2020 年）—— 国家行为者入侵构建系统。
event-stream（2018 年）—— 在热门 npm 包中注入恶意代码。
ua-parser-js（2021 年）—— 维护者账号被劫持发布恶意软件。
node-ipc（2022 年）—— 维护者故意破坏自己的包。
Shai-Hulud / Keyv（2026 年）—— 针对高价值生态圈的协同攻击。
趋势很明显：开源依赖是主要攻击面，而经济因素有利于攻击者。单个被入侵的包可以触及数百万应用。
[INTERNAL_LINK: history of npm supply chain attacks]
长期解决方案不只是"更加小心"。它需要结构性改变：
对 npm 维护者强制要求 MFA（npm 在这方面已有进展，但执行不完整）。
包签名和 provenance 证明成为默认，而非例外。
在 registry 层面进行行为分析，在恶意代码分发之前将其捕获。
为开发者提供更好的工具来理解其完整依赖树。
Q：我如何知道我的应用是否实际受到影响？
A：检查你的 package-lock.json，查找官方公告中列出的任何受入侵版本号。如果找到匹配项，假设在这些版本运行期间，你的环境变量已被窃取。审查网络出口日志，查找与可疑域的连接。
Q：现在还能安全使用 Keyv 吗？
A：可以，一旦你确认运行的是攻击之后发布的已被维护者确认安全的干净版本。Keyv 项目本身是合法的，由活跃贡献者维护。攻击针对的是分发机制，而非库设计的基本缺陷。
Q：npm audit 能捕获此次攻击吗？
A：标准 npm audit 依赖 npm 公告数据库，可能滞后于活跃事件。它现在可能标记受入侵版本，但在初始感染时无法捕获。这就是为什么像 Socket Security 这样的行为分析工具是 npm audit 的宝贵补充。
Q：我是否应该完全停止使用 npm 包？
A：这不是一个现实或相称的反应。npm 生态驱动着现代网络。正确的答案是分层安全：依赖项锁定、lockfile 完整性检查、行为扫描、密钥轮换实践和网络出口监控。将你的依赖树视为需要主动管理的攻击面。
Q：保持了解未来供应链攻击最新信息的最佳方式是什么？
A：订阅 npm 安全公告，关注 OpenSSF 博客，考虑通过 Socket Security 或 Snyk 启用自动化警报。GitHub 安全公告数据库也是出色的免费资源。
供应链攻击不是理论风险——Keyv 及相关包在活跃的 Shai-Hulud 供应链攻击中受损，证明了它们正在发生在当下主流、广泛信任的包上。好消息是保护自己的步骤是具体且可实现的。
你的即时检查清单：
✅ 针对官方公告审计你的 Keyv 依赖版本。
✅ 轮换所有可能已暴露的密钥。
✅ 锁定至已验证的干净版本并使用 npm ci。
✅ 将行为供应链扫描器集成到你的 CI/CD 流水线。
✅ 为未来的依赖入侵设置自动化警报。
不要等下一次事件才认真对待供应链安全。工具存在，实践有据可查，不作为的代价远高于正确实施它的代价。
[INTERNAL_LINK: complete guide to Node.js security best practices]
本文基于 2026 年 8 月可获得的信息撰写。供应链攻击调查进展迅速——在做出依赖决策之前，务必通过官方 npm 安全渠道和受影响项目的 GitHub 仓库验证当前的公告状态。
如需进一步行动，你可以考虑屏蔽此人和/或举报滥用。