标签： pypi

注：本文涉及的部分具体数字、组织名与受影响包清单来自公开报道，文中关于 mistralai 2.4.6 的时间线与处置结果，可在开源项目 Hermes 的安全公告记录中交叉印证。

Mini Shai-Hulud 蠕虫事件（尤其是 2026 年 4 月至 5 月爆发的这一波）是开源软件供应链安全史上的一座分水岭。它不仅波及了 mistralai 2.4.6（PyPI）、lightning 2.6.2/2.6.3（PyTorch Lightning）以及超过 160 个顶级 npm 包（如 TanStack），还打破了传统的防御认知。

以下是关于该事件的全面拆解：

1. 什么是 Mini Shai-Hulud？

Mini Shai-Hulud 是黑客组织 TeamPCP（又名 DeadCatx3）开发的自传播供应链蠕虫（Self-propagating Supply-Chain Worm）。其命名源自《沙丘》中的沙虫（Shai-Hulud），寓意其在代码生态底层如巨虫般吞噬一切。

它的核心特征是自动化雪崩式扩散：

[ 攻陷上游 A 库 ] ──> [ 开发者/CI 下载 A 库并触发恶意代码 ] 
                             │
                             ▼
                    [ 窃取该环境的发布凭证/云密钥 ] 
                             │
                             ▼
 [ 蠕虫自动寻找该凭证有权修改的 B、C、D 库 ] ──> [ 自动提版本号，投毒发布新包 ]

2. 核心技术突破：如何攻破 mistralai 等 AI 库？

以往的供应链投毒通常依靠“钓鱼”或“直接盗取开发者密码”，而 2026 年 5 月 11 日爆发的这一波 Mini Shai-Hulud 采用了极其精密的 CI/CD 缓存投毒与 OIDC 滥用（Trusted Publishing）。

步骤一：利用 Pull Request 机制潜入 (以 TanStack 为跳板)

攻击者首先在 GitHub 上 Fork 目标项目，修改代码后提交一个 Pull Request（PR）。由于目标项目的 GitHub Actions 配置了 pull_request_target 触发器（一种允许在特权上下文中运行 PR 代码的配置），恶意代码在 CI 管道中被执行。

步骤二：凭证窃取与生态跨越

在管道或本地被触发后，蠕虫立即全盘扫描以下敏感信息：

• 发布凭证：.pypirc（Python）、npm tokens。
• 云与基础设施密钥：AWS、GCP、Azure 凭证，以及 Kubernetes 的 kubeconfig。
• CI/CD 密钥：GitHub Tokens、HashiCorp Vault 密钥。

步骤三：无需安装，动态触发（Import 投毒）

对于 PyPI 上的 mistralai 2.4.6 和 guardrails-ai 0.10.1 等 AI 开发库，蠕虫采用了更具隐蔽性的策略：

• 它不需要依赖传统的安装生命周期钩子（如 setup.py 中的执行逻辑）。
• 恶意代码被直接注入到包的初始化文件（如 __init__.py）中。只要开发者或自动化脚本在代码中执行了 import mistralai，蠕虫就会瞬间激活。

步骤四：绕过 SLSA 安全认证（伪造合规性）

这是该事件最恐怖的地方。由于蠕虫是在合规的 CI/CD 管道内通过 OIDC（OpenID Connect 信任发布） 获取的合法签名，它所发布的恶意的 mistralai 2.4.6 竟然带有完备且合法的 SLSA Build Level 3（软件供应链合规）数字签名认证。这直接宣告了“有官方签名就绝对安全”的盲目信任时代破灭。

打个比方：这就像一沓假币，用的却是央行那台真印钞机印出来的——连验钞机都认。签名只能证明“这个包确实由官方流水线产出”，但当流水线本身被攻陷时，它反而成了“合法地输出毒药”的完美背书。

3. 事件的时间线与演进

• 2025 年 9 月 – 12 月（前身出现）：Shai-Hulud 1.0 和 2.0 首次在 npm 被发现，主要通过偷来的 Token 滚雪球式蔓延，后期加入了文件擦除（Wiper）功能。
• 2026 年 4 月 29 日 – 30 日（Mini 版爆发）：蠕虫进化为 Mini 版本，成功感染 4 个 SAP 官方组件，并首次跨越生态投毒了 PyPI 上的 PyTorch Lightning（影响 2.6.2 和 2.6.3 版本，周下载量超 200 万）。
• 2026 年 5 月 11 日 – 12 日（AI 生态大地震）：大爆发。TeamPCP 通过上述 OIDC 链条一次性污染了 169 个 npm 包和多个 PyPI 包，其中就包括 Mistral AI 官方客户端 (mistralai 2.4.6)。
• 2026 年 5 月 12 日晚（开源搞破坏）：TeamPCP 做出恶劣举动，将 Mini Shai-Hulud 的完整源代码公开发布到 GitHub，并在暗网论坛（BreachForums）上大肆炫耀，鼓励其他人效仿。
• 2026 年 5 月下旬 – 6 月（变种狂欢）：由于源码公开，后续爆发了如 Miasma（瘴气）等大量使用相同机理的复制品蠕虫，红帽（Red Hat）的 cloud-services 相关 npm 命名空间也遭到此类变种袭击。

4. 带来的深远影响

1. AI 供应链成为高价值标的：由于 AI 开发者在本地或生产环境中通常拥有极高的算力权限、云存储访问权（如装满训练数据的 S3 存储桶），AI 工具链（Mistral, PyTorch, Guardrails）成为了黑客的重点洗劫对象。
2. 信任链的重构：该事件向安全界证明，CI/CD 自动化发布（Trusted Publishing）虽然防住了“人为泄露密码”，但一旦 CI 本身被毒化，它将变成合法输出毒药的“完美工厂”。企业开始被动转向对每一次构建进行彻底的二进制静态行为审计。

5. 事件的处置与结局

好消息是，针对 mistralai 这条 PyPI 投毒线，社区的响应相当迅速：

• 2026-05-12：PyPI 隔离（quarantine）了 mistralai 项目，恶意的 2.4.6 被从 PyPI 下架。
• 2026-05-25：mistralai 恢复发布干净版本 2.4.7。
• 2026-05-28：再发布 2.4.8，目前已恢复正常。

所以如果你的环境里曾经在 5 月 12 日隔离前装到过 mistralai 2.4.6，正确的处置是：立即卸载该版本，升级到 2.4.7 及以上，并把那台机器上一切可能被读取过的凭证（PyPI/npm token、AWS/GCP/Azure 密钥、GitHub token 等）全部轮换一遍——因为蠕虫的核心目的就是偷凭证，光卸载包并不够。

（以上时间线与处置结果，可在开源项目 Hermes 的 pyproject.toml 与 hermes_cli/security_advisories.py 的安全公告记录中交叉印证。）

6. 对开发者的防御启示

这起事件最有价值的地方，是它把”该怎么防”摆到了每个开发者面前。以下几条是可以立刻落地的：

1. 依赖钉死版本 + 锁文件。不要用 >=2.3.0,<3 这种范围声明——它等于把”什么时候拉新版本”的决定权交给了 PyPI 和时间。改用 ==2.4.8 精确钉死，配合 uv.lock/poetry.lock/package-lock.json 锁住整棵传递依赖树。这样恶意新版本没有自动到达你的通道，只能通过一次显式的人工升级 + code review 才能进来。

2. 核心依赖最小化。直接依赖越少、可选功能越多走”惰性安装”，你的攻击面就越小。一句话概括就是开源圈那句名言：依赖越少，下次供应链攻击波及你的概率越低。

3. 安装期恶意软件拦截。在 pip install/npm install 这一步就接入 OSV、Socket、pip-audit 等工具，对命中”确认恶意软件”公告的包直接 BLOCK。注意区分：拦”确认恶意软件”而不是拦所有 CVE，否则误报会淹没你。

4. 警惕 pull_request_target 等高权限 CI 触发器。这正是本次 npm 侧的入口之一。外部 PR 不应该能在带着仓库密钥的特权上下文里跑代码；CI 里也不要把长期有效的高权限 token 暴露给任意构建步骤。

5. 凭证最小权限 + 定期轮换。假设”迟早会泄漏”来设计：发布 token 用范围最小的、短时效的；云密钥分环境隔离；一旦怀疑某台机器跑过可疑包，立刻轮换。

6. 别迷信”官方签名”。SLSA / 签名能证明”东西是这条流水线产出的”，但证明不了”这条流水线没被攻陷”。签名是必要条件，不是充分条件——仍要结合行为审计和版本钉死。

一句话：供应链安全的核心不是”信任谁”，而是”把每一次自动到达你的通道都收回到一次显式的人工决策”。

如果觉得这篇文章对你有帮助，欢迎点赞、收藏加关注。后续持续分享更多有价值的内容。你的支持是我创作的最大动力！