50万台电脑瞬间沦陷!那个每天被下载340万次的LiteLLM成了定时炸弹

不久前，GitHub 上四万颗星的 LiteLLM，被黑客成功投毒。不到 1 小时，50 万台设备中招。

这些受害者可能根本不知道自己在用它——瞬间大量敏感信息被盗取：AWS 密钥、数据库密码、加密货币钱包、甚至你放在 .env 文件里的所有 API Key。

在中招方式上，这次又很大不同，不是钓鱼链接，不是你手滑点了什么。你只是直接或间接使用LiteLLM就会中招。

这场攻击之所以被发现，纯属意外。

FutureSearch 的开发者 Callum McMahon 正在 Cursor 里跑一个 MCP 插件。插件自动更新了依赖，拉取了最新版的 LiteLLM。

然后，他的电脑风扇开始狂转，系统直接卡死。

排查后发现，恶意代码里有个致命的递归 Bug：每次 Python 启动，它就疯狂创建子进程，子进程再创建子进程，无限套娃直到内存榨干。

病毒原本想安静潜伏，悄悄偷走你的密钥。结果这个 Bug 直接把「中毒」写在了脸上。

102 秒内，黑客动用了僵尸账号网络，往 GitHub issue 下面灌了 88 条垃圾评论，试图淹没真正的警告。然后直接登录窃取的维护者账号，强行关闭了讨论区。

但为时已晚。

LiteLLM 的定位很简单：用同一套代码，统一接入 ChatGPT、Claude、Gemini 等几十个大模型。

Y Combinator 背书，月下载量近 1 亿次。它卡在用户和所有 AI 工具之间，成了事实上的「基础设施」。

大量 MCP 插件、Agent 框架，底层都依赖它。

这意味着什么？就算你从来没主动装过 LiteLLM，只要你用了任何一个依赖它的工具，你就已经暴露了。

你甚至不知道自己装了它。但它就在那儿，知道你所有的秘密。

这次攻击最精妙的地方，是黑客没有直接碰 LiteLLM 的服务器。

他们盯上的是 Trivy——一个开源安全扫描工具，相当于代码发布流水线上的「保安」。

通过篡改 Trivy 的自动提交配置，黑客在 LiteLLM 发布时，顺手拿到了官方密钥。然后大大方方发布了带毒版本 1.82.7 和 1.82.8。

签名是真的，校验全过。系统看来，这就是官方正版。

更细思极恐的是投毒手法。

黑客利用了 Python 的启动钩子机制。你不需要写一行代码引入这个库，只要 pip install 完成，恶意代码就自动激活。

启动 Python 的那一刻，它就在后台运行了。

它会扫描你的环境变量、~/.ssh 目录、AWS/Google Cloud 凭证文件。如果你是 AI 开发者，所有大模型的 API Key 都会被翻出来。如果你有加密货币钱包，助记词会被打包成 tpcp.tar.gz，加密后发送到黑客的伪装域名 models.litellm.cloud。

整个过程，你毫无感知。

攻击流程图

这件事暴露的，是整个开源生态的结构性溃败。

「不要重复造轮子」是软件开发的圣经。但代价是什么？

随便打开一个 Python 项目的 requirements.txt，几十上百个依赖，每个又有自己的依赖。依赖树深达七八层，横跨几百个包，维护者遍布全球——有大厂工程师，有学生，也有三年没登录 GitHub 的幽灵账号。

你以为在信任一个包，实际在信任整棵你看不见的树。

任何一个节点被攻陷，危险就会顺流而下，直达你的机器。而你的防御手段？看一眼下载量，确认够大，然后按回车。

开源安全的底层假设是「足够多的眼睛在看」。但 2026 年的现实是：不是眼睛不够多，是没人再用眼睛看了。

为什么这次事件特别危险？

因为它踩中了三个雷区的交汇点：

-

AI 编程工具的爆发：Cursor、Windsurf 等工具让「说话就能写代码」成为现实，也带来了「说话就能装恶意包」的风险

-

供应链的复杂度爆炸：现代项目的依赖树已经复杂到人类无法审计的程度

-

安全基础设施的滞后：PyPI 没有强制签名验证，包管理器无法可靠回答「这个版本真的是官方发的吗」

以前装一个包，好歹是你查了文档、比较了方案后的主动选择。

现在的流程是：告诉 AI「帮我做个功能」，AI 写好代码，报错，自动补一句 pip install xxx，你瞥一眼，按回车。

就这么一下。你不知道装了什么，不知道为什么装，只知道 AI 说这样能修好。

「人人都能成为开发者」的另一面是：人人都能成为供应链攻击的受害者。

AI 降低了写代码的门槛，也降低了被投毒的门槛。而且幅度完全不对等——写代码从「学三年」变成「说一句话」，被投毒从「犯一个错误」变成「什么都不用做」。

AI编程风险示意图

Karpathy 说他越来越不愿意用第三方依赖，倾向让 LLM 直接生成功能代码。但这其实是「何不食肉糜」——能自己写代码的人，本来就不是攻击的主要目标。

真正的受害者，是那些连 pip install 装了什么都看不懂的新用户，是被 AI 工具带进来的百万新开发者。

告诉他们「自己写别用依赖」，等于告诉刚拿驾照的人「自己造车别买车」。

LiteLLM 事件会被修复，但结构性问题不会消失。

在更好的安全范式出现之前，我们能做的很有限，但也不是完全无能为力：

对个人开发者：

- 每次按 Enter 前，停一秒想想「这个工具我真的需要吗」

- 用 pip freeze 定期检查依赖，删除不再使用的包

- 敏感项目考虑用虚拟环境隔离，最好是物理隔离

- 重要凭证不要放在项目目录，用专门的密钥管理工具

对团队/企业：

- 建立私有 PyPI 镜像，审计后再放行

- 使用依赖扫描工具（但记住，这次攻击就是利用了安全扫描工具本身）

- 对关键依赖做代码审查，哪怕只是抽查

对行业：

- 推动包管理器的签名验证机制

- 建立依赖树的「可审计性」标准

- 重新思考「不重复造轮子」的边界

这次LiteLLM事件，最可怕的是你什么都没点，就中招儿了。

工具的能力已经是 2026 年的，安全意识和基础设施还停在 2019 年。这个剪刀差，才是 LiteLLM 事件真正让人不安的地方。

过去，最危险的是点开钓鱼链接。现在，最危险的是你什么都没点击。

因为 AI 已经替你做了所有选择，你只需要确认——用那个最轻的动作，按下回车。