你的代码还安全吗？一次普通安装，竟让恶意脚本潜入开发环境！

现代软件开发早已变成了积木式协作，一个项目不会从零写完所有代码，开发过程中必然依赖成百上千个第三方库。

对于普通开发者来说，安装依赖就像从仓库里取零件，这些零件都来自 PyPI、npm、Maven、Cargo 这样的公共软件仓库。

这样做的好处在于，让开发效率大幅提高；坏处在于，让信任关系变得更复杂，安全投毒更易发生。

本质上，安装一个依赖时，是在允许外部代码进入自己的电脑、开发环境或者云服务器。

问题是，几乎没有开发者会去认真审查外部依赖库的代码，普遍是采取默认安全的态度。

Lightning PyPI 包被投毒攻击，就是基于使用/调用者的这种默认态度。

从目前得到的信息来看，攻击者拿到了 PyPI 发布凭据，克隆开源代码、注入 payload，然后直接向 PyPI 发布 2.6.2/2.6.3，绕过了 GitHub 源码仓库，恶意版本在 PyPI 存活约 42 分钟后被隔离/删除。

要知道，这次投毒事件，攻击者污染的并非一个冷门山寨包，这可是 PyPI 上正牌的 Lightning 包版本。Lightning 是 Python 机器学习生态中使用广泛的框架，很多人用它组织训练代码和管理分布式训练等等。

目前来看，受影响的Lightning 版本主要是 「2.6.2」 和 「2.6.3」，最后已知干净版本通常被认为是 「2.6.1」。

其实，对于开发者来说，其本身也很无辜，或者说委屈，因为其没有去下载来路不明的软件，也没有主动运行一个陌生脚本，只是像平时一样安装了 Lightning，如此而已。

谁会知道，在机器学习项目中再普通不过的「import lightning」，在特定版本突然就被投毒了呢。

而且，这次投毒类似于「0 click」攻击，也就是说，受污染版本的 Lightning 在被导入时，会悄悄启动隐藏在包内部的恶意逻辑，攻击触发点并不需要用户额外执行什么奇怪命令，正常导入库这个动作就足够了。

对于一个被如此广泛使用和导入的包来说，这种几乎无法防住。

目前，从包结构来看，恶意代码主要藏在 Lightning 包内部的运行时目录里，

对于受害者来说，主程序仍然可以继续执行，用户看到的训练脚本、Notebook 或测试流程可能都没有明显异常，这也是这次攻击的隐蔽性之一。这类设计非常符合供应链攻击的思路。攻击者通常不希望程序立刻崩溃，因为崩溃会让用户马上警觉。

一个好的投毒包会尽量维持原有功能，让用户相信一切正常，比如Lightning 这次的恶意版本。

也就是说，攻击者把 PyPI 当作入口，把 JavaScript 当作核心执行层，Python 生态协助攻击者进入机器学习开发环境，JavaScript 载荷负责执行已经成熟的凭据窃取、仓库投毒和 npm 传播。

分工明确，非常合理。

不过，投毒者其实也做了防护，那就是其对这个js进行了高度混淆，这样做有两个目的：拖慢安全研究人员的分析速度，同时降低静态扫描工具直接识别恶意逻辑的概率。

对于安全分析人员来说，要先解混淆才能分析，这就给了病毒运行一定的时间缝隙。

还原之后可以看到，这个恶意脚本首先关心的是凭据，恶意脚本会扫描整个系统，寻找 GitHub 访问令牌、npm 访问令牌、云平台密钥、OAuth token 和各种 CI/CD secret，以及等等等等，写的还挺全面。

恶意脚本还会尝试访问云环境中的元数据地址，例如常见的「169.254.169.254」和容器任务凭据地址「169.254.170.2」。

一旦恶意代码已经在机器上运行，它就可以在有效期内利用这些权限来做恶意操作、横向移动，提权和数据泄露等等。

此外，脚本还会验证这些凭据是否有效，以此直接在本地筛选出有价值的权限。例如，它会调用 GitHub API 判断 token 能访问哪些仓库，也可以调用 npm registry 的身份接口判断 npm token 是否可用。

每个被污染的提交都是使用硬编码的身份编写的，这样做的目的是模仿 Anthropic 的 Claude Code，导致 GitHub 的用户界面将claude显示为仓库的贡献者。

对于普通开发者，这种提交在视觉上与 Claude Code 的合法操作并无区别。现在很多开发团队已经习惯 AI 工具了，这就使得投毒攻击的传播更加隐蔽了。

纵观整个传播了，最初的入口是 PyPI 上的 Python 包，后续执行层是 Bun 和 JavaScript，传播目标包括 GitHub 仓库和 npm 包。

对于我来说，这次供应链攻击最新鲜的莫过于其在污染GitHub仓库时使用了Claude 这个提交角色，这是以往LLM没出现前所没有遇到的情况，非常的新奇，但是仔细一想也确实非常的有新意，而且，看得出来是经过仔细的考虑，非常有创意。

对于普通开发者，判断自己是否受影响，关键看两个条件：是否安装过 「lightning==2.6.2」 或 「lightning==2.6.3」，是否在该环境中执行过 「import lightning」 或运行过会导入 Lightning 的脚本。

如果有的话，马上卸载包，并且检查和更换各类凭证。重点处理 GitHub token、npm token、PyPI token、AWS、Azure、GCP 密钥、CI/CD secrets、模型仓库 token 和任何曾经出现在环境变量中的敏感信息。

目前来看，检查完之后，可以先回退到安全版本「2.6.1」来使用。

这件事再一次提醒各位，供应链安全一定要重视，开源和三方库，不一定意味着安全。