【AI风向】Mistral AI官方npm包遭供应链攻击：169个包被植入自传播蠕虫，你的项目安全吗？
5月11日晚，一场针对npm生态系统的自传播蠕虫攻击席卷了169个JavaScript包——法国AI明星公司Mistral AI的官方npm包赫然在列。攻击者通过劫持CI/CD流水线，让恶意代码携带"合法签名"进入开发者项目。
事件回顾
2026年5月11日晚22:45（UTC），npm包注册表上突然出现了三个恶意版本的 @mistralai/mistralai：v2.2.2、v2.2.3、v2.2.4，在8分钟内连续发布。这三个版本全部包含一个名为 setup.mjs 的恶意预安装脚本——而最后一个安全版本 v2.2.1 的 package.json 中根本没有 preinstall 字段。
这并非孤立事件。它是代号"Mini Shai-Hulud"的自传播供应链蠕虫攻击的最新一波——攻击范围已从最初的TanStack生态扩展到 Mistral AI、UiPath、DraftAuth 等169个npm包。StepSecurity的安全团队在5月11日确认了这次攻击，Mistral团队已紧急下架所有受感染版本。
攻击者的手法令人惊骇：他们劫持了npm包的CI/CD发布流水线，利用GitHub Actions的OIDC令牌直接在npm上发布恶意版本。由于这些版本由合法的CI/CD管道生成，它们携带真实有效的SLSA来源证明——这意味着即使是开启了供应链安全验证的企业，也会将这些恶意包视为"可信"。
为什么重要
这次攻击对AI开发者有三大直接威胁：
1. AI工具链成攻击目标。 Mistral AI是欧洲最有价值的AI公司之一，其npm包 @mistralai/mistralai 被大量AI项目用于调用Mistral的API。攻击者选择Mistral作为目标，说明他们正在主动瞄准AI开发工具链——这是连接数万AI应用的咽喉要道。
2. 蠕虫具有自传播能力。 与传统的"投毒-等人下载"模式不同，Mini Shai-Hulud 在感染一个环境后会自动窃取GitHub Token和npm凭证，然后用这些凭证去感染更多包。这意味着一个开发者的机器被感染，可能导致其维护的所有npm包连锁沦陷。StepSecurity发现的373个恶意版本中，大量来自被劫持的合法发布者身份。
3. 攻击绕过了企业级安全防线。 由于使用了CI/CD原生发布流程，恶意包携带的SLSA签名完全合法——现有的供应链安全工具无法区分"正常的CI/CD发布"和"被劫持的CI/CD发布"。这是一个安全范式的根本性挑战：来源证明只能验证"谁发的"，不能验证"发的时候是否被操纵"。
技术细节：攻击是如何实现的
攻击分为三个阶段：
阶段一：Payload潜伏在Fork中。 攻击者在GitHub上创建了目标仓库的Fork，在其中植入两个文件：一个伪造的 @tanstack/setup 包（通过 optionalDependencies 引用GitHub URL加载），以及一个2.3MB的混淆JavaScript文件 tanstack_runner.js。
阶段二：注入到真实包中。 攻击者修改目标包的 package.json，加入 optionalDependencies 字段指向Fork中的恶意包，同时在包根目录植入 router_init.js（2.3MB混淆代码）。
阶段三：通过CI/CD原生发布。 恶意代码不直接发布——它利用窃取的GitHub Actions OIDC令牌，调用npm publish 通过合法的CI/CD流程发布。结果：恶意包带有真实的SLSA来源证明，签名链完整。
Payload的核心能力包括：10个专用凭证收集器（针对GitHub Token、npm Token、SSH密钥、AWS凭证等）、AES-256-GCM加密混淆、通过 sfrclak.com:8000 外传数据（该域名已被封锁），以及在窃取凭证后自动感染该凭证可访问的其他npm包。
你的项目安全吗？立即自查三步
第一步：检查依赖链。 运行以下命令查看你的项目中是否引入了受感染的Mistral包或其传递依赖：
npm ls @mistralai/mistralai
grep -r "mistralai" package-lock.json第二步：锁定安全版本。 在 package.json 中添加 npm overrides：
"overrides": {
"@mistralai/mistralai": "2.2.1"
}npm install 强制所有传递依赖降级到安全版本。
第三步：轮换凭证。 如果你的CI/CD环境在过去24小时内安装过受感染包，假设所有secrets已泄露，立即轮换：
- GitHub Personal Access Token
- npm publish token
- 项目中的 API keys（Mistral、OpenAI等）
- 环境变量中的所有密钥
我们能学到什么
这次攻击为AI创业者敲响了三个警钟：
依赖即风险。 你在 npm install 一个AI SDK的时候，可能同时引入了100+个传递依赖——每一个都是潜在的入口。Mistral的npm包被攻击，不是因为它不安全，而是因为它的发布流水线依赖了外部系统（GitHub Actions），而那个系统可以被攻击者利用。
签名≠安全。 SLSA/Build Provenance等供应链安全标准正在普及，但这次攻击暴露了它们的根本局限：签名只能证明"谁在什么环境下发布的"，无法证明"发布者当时是否被胁迫"。安全需要多层次——签名只是其中一层。
隔离你的CI/CD。 如果你的开源项目的GitHub Actions配置了 id-token: write 权限，攻击者就可以通过一次依赖污染获得你的发布权限。建议：为发布流程使用独立的、受限的GitHub App Token，不要使用Actions的默认OIDC令牌。
#AI创业 #供应链安全 #npm #MistralAI #一人公司 #AI开发安全
本文由AI辅助创作，经人工审核编辑发布