大模型 Python 库 litellm 被投毒,不要更新,不要更新,不要更新

今天不聊模型效果，聊一个非常致命的安全问题。就在昨天，AI 圈出了个大事，很多项目每天都在用的 litellm 被人下毒了！

LiteLLM 是一个在 AI 开发中非常流行和关键的开源 Python 库，它就是大语言模型（LLM）时代的“万向节”或“万能插座”。核心作用是：提供一个统一的接口（完全兼容 OpenAI API 的格式），让你能够无缝调用市面上几乎所有的主流大模型（支持超过 100 多种 LLM）

正因为它的便捷性，目前很多 AI 应用、脚手架、开发工具（比如 dspy、某些 Cursor 的 MCP 插件、各种 Agent 框架）都在底层偷偷依赖了它来处理多模型调用的问题。这也解释了为什么它一旦“被投毒”，就像水厂被投毒一样，只要间接喝到水的项目全都会遭殃。

可能被收集的信息

litellm 是一个很重要的依赖，我也查了一下，也安装的有，目前的版本还是安全的

简介

2026年3月24日，一个名为 1.82.8 的 litellm 版本被悄无声息地发布到了 PyPI 上。之所以说它悄无声息，是因为 GitHub 仓库里根本没有这个版本的 release 或者 tag，黑客是直接越过常规流程，把受感染的包强推到了 PyPI。

这个包里夹带了私货：一个名为 litellm_init.pth 的文件，34KB 左右大小。做过 Python 开发的都知道，只要环境里存在 .pth 文件，Python 解释器在每次启动时就会自动执行里面的内容，甚至你都不需要 import litellm。这招非常毒。

更要命的是，即便是你从来没主动去 pip install litellm，你也极有可能中招。很多开源项目（如 dspy，依赖 litellm>=1.64.0）或者由于在使用 Cursor 的 MCP 插件时（通过 uvx 自动拉取依赖），都在不知不觉中引入了这个带毒的包。也就是说，享受着便捷的现代工具的同时，黑客在底层给你悄无声息地投毒了。

以下是相关推文的提示：

甚至 Andrej Karpathy 大神都在 X 上吐槽说，这是一个 "Software horror"（软件界的恐怖故事）。简单地 pip install litellm，瞬间就会让你的一切底裤被看光：SSH 密钥、环境变量里所有的 API Key、云上凭证、Kubernetes 配置，甚至是加密钱包...

正如他所说："现代软件里最大的隐患，就是这深不见底的依赖树。"

毒发细节（技术深挖）

黑客到底是怎么干的？其实整个动作非常简单粗暴。

一旦受感染的 litellm_init.pth 被 Python 执行，它会启动一个子进程，执行经过双重 base64 编码的恶意代码。 这段代码的执行分为十分疯狂的三步：

第一阶段：大扫除式的信息收集脚本就像个饿汉，疯狂搜刮你电脑上的所有的秘密。

• 所有的 SSH 私钥 (~/.ssh/id_rsa, ~/.ssh/config 等等)。
• 你的环境配置 (printenv 抓走你所有的 API Keys)。
• AWS、GCP、Azure 的鉴权凭据以及 Kubernetes ~/.kube/config。
• Shell 的历史记录 (.bash_history, .zsh_history)、甚至是数据库连接配置。
• 还有诸如各个加密钱包文件和 SSL/TLS 的私钥。 简单来说，只要是你放在电脑里稍微有点价值的东西，它全搜罗了一遍。

第二阶段：打包传输在获取了这堆极其致命的信息后，恶意脚本通过 openssl rand 随机生成一个 32 字节的 AES-256 密钥，并将上述所有的战利品加密。这一步非常狡猾，它用写死的一段 4096 位 RSA 公钥通过 OAEP 填充把这个 AES 密码给加密了，最终打包成 tpcp.tar.gz 文件。 然后发送到一个极具欺骗性的自建域名上：https://models.litellm.cloud/，不知道的还以为是官方的功能接口。

第三阶段：横向感染如果受害者运行在 Kubernetes 环境中，它会扫描所有的 cluster secrets，并尝试在所有的节点上跑个特权容器（Alpine Latest），再给所有宿主机留下个持久化后门 ~/.config/sysmon/sysmon.py 以及 systemd 守护服务。

实测与反思

之所以这次黑客投毒这么快被抓住，完全是因为黑客的代码写得太烂了。

FutureSearch 团队里有个小哥叫 Callum McMahon，他正好在 Cursor 里面跑的一个过期的本地 MCP 服务依赖了这玩意。

因为 .pth 机制的特殊性，恶意脚本用 subprocess.Popen 调用了一个 Python 子进程。悲剧发生了：因为子进程也是个 Python 进程，它一样会触发执行 .pth。接着，子进程又会触发子进程……好家伙，这成了一个完美的无限递归。

最后的结果是，这哥们的电脑内存直接被爆破，导致当场死机。如果黑客多花点心思测一测（没准这段代码就是用大模型随便糊弄生成的呢？）不搞出这个低级的 fork bomb 崩溃 bug 的话。估计这个毒包会在很多公司的生产环境里潜伏数周，那就真的是不可挽回的灾难了。

总结

这起利用供应链攻击获取隐私信息的事件给我们敲响了警钟。 如果你的项目碰巧或者间接在近两天安装或更新了依赖 litellm>=1.82.8 的库（或者你的 ~/.cache/uv 里能翻出 litellm_init.pth）：

1. 立即删除、清空 pip / uv 的 cache。
2. 重置所有 credential。如果你被感染，请默认你所有的 SSH Key，云上配置甚至银行密码等已经报废，赶紧换新！

这件事就像 Karpathy 说的，在现代软件工程体系下，把复杂性推给无数的依赖包，其实是很危险的一件事。面对 AI 爆发式生长的同时，我们也需要更加关注安全隔离。遇到简单的需求，直接用大模型用原生语言 "Yoink" (缝合) 代码，而不是去糊里糊涂地拉一堆你这辈子都看不完代码的第三方库，或许才是真正的自保之道。

官方链接留底（虽然官方已经把受感染的版本下架清理了，但依旧触目惊心）：