LiteLLM投毒事件：1705个依赖包把开发者电脑变成"明文保

2026年3月，一个被下载数百万次的AI开发库，让全球开发者的笔记本变成了攻击者的自助提款机。

TeamPCP组织向LiteLLM的PyPI包植入了窃密木马。这个库每天被下载数百万次，开发者用来统一管理OpenAI、Claude、Gemini等几十种大模型接口。攻击者没费什么劲——恶意代码只是安静地读取开发者本地已经存在的明文凭证。

攻击链：两小时窗口期的精准收割

被污染的版本是1.82.7和1.82.8。GitGuardian的分析显示，恶意包上线后，1705个PyPI包配置了自动拉取这些版本作为依赖。其中包括月下载500万的dspy、300万的opik、140万的crawl4ai。

这意味着什么？一家从没直接装过LiteLLM的公司，可能因为用了某个AI爬虫工具，就在`pip install`时把整个AWS根密钥拱手送出。PyPI在几小时内下架了恶意包，但依赖链的级联效应让攻击窗口被大幅拉长。

木马激活后做的事很"朴实"：遍历.ssh目录拿私钥，读~/.aws/credentials，翻Docker配置文件，检查shell历史记录里的token，甚至瞄向AI代理的内存存储。都是开发者机器上本来就有、且几乎从不加密的东西。

开发者终端：企业最活跃的"凭证沼泽"

安全团队常把防火墙、数据库、生产服务器当重点。但TeamPCP这类攻击者早就换靶子了——开发者笔记本才是企业基础设施里最活跃的节点。凭证在这里被创建、测试、缓存、复制，然后流向机器人、构建工具、本地AI代理。

GitGuardian之前分析的Shai-Hulud campaign提供了更刺眼的数字：6943台被攻陷的开发者机器里，检出33185个唯一密钥，其中3760个仍然有效。每个有效密钥平均在机器的8个不同位置出现。59%的沦陷系统是CI/CD runner，不是个人笔记本。

攻击者现在的打法像反向漏洞扫描。他们用同样的系统化方法遍历文件系统，只是目标不是找漏洞，而是找明文存的密钥。环境变量、IDE设置、构建产物、临时脚本、调试输出——秘密在开发者机器上活得像野草，到处都是，且从不设防。

为什么明文凭证杀不死

每次供应链攻击后，安全社区都会复读"要用密钥管理服务""要轮换凭证"。但现实是，开发者需要快速迭代，把密钥塞进.env文件是最短路径。这些文件本该只在本地存在，却随着dotfiles仓库、备份脚本、协作截图四处漂流。

LiteLLM的恶意代码甚至不需要提权或漏洞利用。它只需要读取当前用户有权限访问的文件——而开发者为了工作顺畅，通常对自己的home目录有完全控制权。权限模型在这里成了帮凶：攻击者用开发者的合法权限，做开发者自己每天都在做的事。

更隐蔽的是AI代理带来的新攻击面。Cursor、Claude Code、Devin这类工具会把API密钥、数据库连接串、内部端点地址存进对话历史或内存索引。这些存储位置对传统安全扫描几乎透明，但对植入开发环境的木马来说，只是另一批待收割的明文文件。

供应链的"信任复利"陷阱

PyPI、npm、Maven Central的设计假设是：发布者可信，版本号诚实，依赖解析透明。但现代项目的依赖树深度让这套假设破产。一个AI应用可能间接依赖200个包，每个包又有自己的200个依赖。

TeamPCP没有攻击LiteLLM的GitHub仓库或核心开发者账号——他们直接上传了同名包的恶意版本，利用的是PyPI对版本发布的即时生效机制。包管理器的"方便"设计，在这里变成了攻击者的快速通道。

GitGuardian的检测系统在恶意包下架前捕获了部分信号，但大多数组织缺乏对依赖变更的实时监控。当`pip install`或`npm ci`成为CI/CD流水线的标准步骤，恶意代码的执行也就成了"正常"的构建活动。

这次攻击的后续影响还在发酵。被窃的凭证有多少已被转卖？哪些组织的云环境正在被横向移动？GitGuardian没有公布受害名单，但1705个直接依赖包意味着受影响范围远超LiteLLM的直接用户。

你的开发环境里，现在有多少个.env文件？上次检查它们的内容是什么时候？