一个 AI 训练团队最平常的动作，可能就是这次攻击的入口：pip install lightning，然后在代码里 import lightning。
Semgrep 披露，PyPI 上的 lightning 包在 2026 年 4 月 30 日发布的 2.6.2 和 2.6.3 版本中被植入恶意代码。安装后导入模块，隐藏在 _runtime 目录里的混淆 JavaScript payload 会执行窃密，并尝试污染 GitHub 仓库。
这件事最扎眼的地方，不是“又有一个包出事”。而是 AI 训练库这种高信任入口，被拿来偷凭证、偷 token、偷云密钥。训练效率越高，依赖入口越多；入口越多，门闩就越不能靠运气。
受影响的不是所有 PyTorch，而是这两个 lightning 版本
边界要讲清楚。
不能说所有 PyTorch 环境都受影响，也不能断言 PyTorch Lightning 官方整体被攻破。目前能确定的风险，集中在 PyPI 的 lightning 包 2.6.2 和 2.6.3，以及安装后触发导入的环境。
| 项目 | 信息 |
|---|---|
| 受影响包 | PyPI 上的 lightning |
| 受影响版本 | 2.6.2、2.6.3 |
| 发布时间 | 2026 年 4 月 30 日 |
| 触发条件 | 安装后导入模块 |
| 恶意载荷 | _runtime 目录中的混淆 JavaScript payload |
| 窃取对象 | 凭证、认证 token、环境变量、云密钥 |
| 额外行为 | 尝试污染 GitHub 仓库 |
| 关联迹象 | Semgrep 认为与 Mini Shai-Hulud 活动有关，包括 EveryBoiWeBuildIsaWormBoi 公开仓库命名 |
“Semgrep 认为”这几个字不能省。
Mini Shai-Hulud 的关联，目前应按研究方判断理解。它可以帮助安全团队定位线索，但不是司法级归因。写供应链安全，最怕两头失真：要么轻描淡写，要么把研究判断写成定案。
真正该动手的是两类人。
AI/ML 工程团队要查训练环境、notebook、CI 镜像、容器镜像、lockfile。尤其是做图像分类、LLM 微调、扩散模型、时间序列预测的团队，哪怕没直接写 lightning，也要看依赖树有没有把它带进来。
负责依赖治理和供应链安全的人，别只等漏洞公告。先把 2.6.2、2.6.3 拉进阻断规则，再查 GitHub token、云密钥、环境变量是否暴露过。命中环境不应只删包，还要轮换凭证，检查仓库异常提交和异常公开仓库。
可直接做的排查动作很朴素：
- 查当前环境.
pip show lightning - 查依赖冻结文件.
pip freeze | grep lightning - 查 lockfile、镜像构建文件和训练容器历史层
- 查 GitHub 账户或组织下是否出现异常仓库、异常提交
- 查云平台访问日志和 token 使用记录
这不是优雅工程。是止血。
反常点：AI 训练库成了凭证入口
Python 生态有个默认信任：装包是开发动作，导入是运行入口。攻击者盯上的就是这个默认。
AI 训练环境尤其肥。
环境变量里常有云密钥、模型平台 token、对象存储凭证。训练机能访问数据集、模型权重、内部仓库。CI 和实验脚本为了省事，经常把权限开得很宽。
这和传统业务服务还不一样。业务系统上线前通常有发布流程，训练脚本却常在实验压力下快速迭代。今天换依赖，今晚跑实验，明早看指标。安全审核跟不上这个节奏。
早年的 npm、PyPI 供应链攻击，打的是软件构建链。现在同一套玩法进了 AI 训练链。场景不完全一样，但权力结构很像：谁能进入依赖树，谁就可能进入生产路径。
铁路时代，事故不只发生在火车头，也发生在道岔和信号系统。AI 训练库就是今天的道岔。它不一定显眼，但一旦被扳错，整条线路都跟着跑偏。
我不太买账一种安慰：只要团队没直接安装这两个版本，就没事。
现实没这么干净。AI 项目的依赖树深，基础镜像复用多，notebook 环境常年不清。很多团队说不清一台训练机上到底装过哪些包，更说不清哪个 token 被哪个脚本读过。
问题不在某个开发者手滑。问题在激励设计。
模型要快，实验要快，迭代要快。依赖审核、权限切分、密钥轮换，短期看都在拖慢速度。于是团队把安全债留给以后。攻击者不会等以后。
现在该看的不是热闹，是依赖治理有没有上桌
这次事件给技术负责人递了一张很难看的账单：AI 工程不能只盯 GPU 利用率、训练吞吐和 benchmark。依赖入口也要进核心指标。
最小动作不复杂。
| 角色 | 现在该做什么 | 现实约束 |
|---|---|---|
| AI/ML 工程团队 | 固定版本，排查 2.6.2/2.6.3，清理训练环境，轮换疑似暴露 token | 实验节奏会被打断，部分环境难以复现 |
| 安全与平台团队 | 建立高权限环境依赖准入，扫描 lockfile 和镜像，收紧 GitHub 与云权限 | 需要和研发流程绑定，不能只靠事后工单 |
这里有个残酷现实：很多 AI 团队不是不知道该做，而是没人为这件事付账。
安全策略会降低一点速度。权限切小会增加一点麻烦。锁版本会让升级变慢。可训练环境一旦泄露云密钥，代价就不是慢一点，而是仓库、数据、模型资产一起暴露。
“天下熙熙，皆为利来。”放到开源供应链里并不突兀。攻击者盯上的不是包名本身，而是包背后的通行权。一个训练库进了 CI、notebook、镜像和集群，就可能拿到比普通业务依赖更敏感的位置。
接下来判断风险，别看口号，看三个变量。
第一，你的环境是否命中过 2.6.2 或 2.6.3。没有命中，风险会低很多；命中过，就按凭证可能暴露处理。
第二，token 权限有多大。如果训练容器能读写全组织仓库，或者云密钥能访问大范围资源，那不是一个包的问题，是权限设计的问题。
第三，团队能不能从 lockfile、镜像、CI 记录里还原依赖历史。还原不了，说明安全团队连事故边界都画不出来。
AI 基建这两年很热，热到很多人把“能跑起来”当成主要胜利。可工程系统的成熟，不是看跑得多快，而是看出事时能不能刹住。
这次 lightning 事件不需要被夸大成行业灾难。它更像一次冷水提醒：模型训练链路已经成了高价值攻击面，而很多团队还在用脚本时代的信任方式管理它。
训练效率不是免费午餐。你把信任交给依赖树，依赖树迟早会向你收费。