50万台电脑被「下毒」，AI时代最危险的操作，不是点链接，是按回车

发布时间：2026-03-25来源：APPSO

GitHub 上四万颗星，日均下载 340 万次，几乎是 AI 开发者电脑里都会出现的基础设施。

LiteLLM，昨晚被黑了。

只要你用过它，或者用了任何一个间接依赖它的工具，你电脑上的东西就会被打包带走：远程连接的私钥、AWS/GCP/Azure 各种云账号、部署平台密钥、加密货币钱包、数据库密码，还有你放在 .env 文件里的所有 API Key。

打包好，发走，目的地是黑客提前架好的服务器。

不需要点任何钓鱼链接，不需要下载任何可疑文件，甚至不需要犯任何错误；代码装上，它就自己跑了。

根据 BleepingComputer 报道，有消息人士透露，不到 1 小时，约 50 万台设备中招。

但整件事最离谱的地方在于，这波攻击之所以被发现，靠的完全是运气。黑客自己写的恶意代码里有个 bug，把一台机器的内存直接撑爆了。

计划堪称完美，结局属实拉胯。

挑了最理想的目标，留了个最糟糕的 Bug

先说说 LiteLLM 是什么来头。

官网写着「Y Combinator 支持」，主要的功能是用同一套代码接入 ChatGPT、Claude、Gemini 等几十个大模型，每月下载量接近 1 亿次。

项目官网：https://www.litellm.ai/

它的位置，刚好卡在用户和所有 AI 工具之间。大量 MCP 插件、Agent 框架，底层都依赖这个 Python 包。就算你从来没主动装过 LiteLLM，只要你用了任何一个依赖它的库，你就已经暴露了。

你甚至不知道自己装了它。但它就在那儿。

黑客组织 TeamPCP 显然也看中了这一点。他们没有直接去攻击 LiteLLM 的服务器，而是选了一条更阴的路：供应链攻击。

怎么理解？普通黑客攻击，是去撬你家门锁。供应链攻击，是在锁出厂之前，就已经设置了一个缺口。

他们盯上的突破口，是 Trivy。这是一个开源安全扫描工具，相当于代码发布流水线上的保安，前不久 Trivy 也曾报告遭受过 AI 攻击，一度清空了项目仓库。

黑客也是看中了这点，篡改了 Trivy 的自动提交配置。当 LiteLLM 照常发布，毫无防备地拉取这个被污染的「保安」进行安全检查时，黑客顺手就拿到了发布包的密钥。

LiteLLM 还取得了多项安全认证

接下来的操作就很丝滑了。拿着官方密钥，他们大大方方地发布了带有恶意代码的 LiteLLM 1.82.7 和 1.82.8 版本。因为签名是真的，所有常规校验全部通过。在系统看来，这个有剧毒的安装包，就是一个有着官方签章的安全发行版。

没有任何异常提示。没有任何红旗。什么都没有。

更让人后背发凉的是这次的投毒手法，黑客利用了 Python 的启动钩子机制。

简单说，你不需要写一行代码来引入这个有毒的库。只要在终端敲一行 pip install，恶意代码瞬间激活。毫不夸张的说，只要你启动了 Python，它就在跑。

相关的事件报告：https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm

它会扫你本地的环境变量、远程连接密码，精准抓取 AWS、Google Cloud 的连接凭证。如果你是 AI 开发者，它会翻遍你本地存的所有大模型 API Key。如果是加密货币玩家，比特币、以太坊钱包的助记词，也会被打包成一个名叫 tpcp.tar.gz 的压缩包，加密处理后，悄悄发送到黑客前一天刚注册的伪装域名 models.litellm.cloud 上。

攻击链路，教科书级别，但是毁在了一个无限套娃的 bug 上。

被一台风扇狂转的电脑拯救的开源社区

FutureSearch 的开发者 Callum McMahon，需要在 Cursor 里跑一个 MCP 插件。插件安装依赖的时候，顺带拉了最新版的 LiteLLM。

然后，他的电脑风扇开始发疯。系统彻底卡死。

排查了一阵后，他在 LiteLLM 1.82.8 里找到了元凶：一段隐藏的恶意代码，每次 Python 启动都会自动运行，疯狂启动子进程，子进程再触发同样的恶意代码，然后继续启动新的子进程。

套娃，一直套，直到内存被榨干。

病毒原本的计划是安静潜伏，悄悄打包你的密钥带走。结果因为这个失控的递归 bug，直接把电脑卡到明面上了。

有网友说，这黑客的攻击代码，搞不好也是 AI vibe coding 出来的。考虑到 bug 的低级程度，这个猜测的可信度其实不低。

目前，反馈这个问题的帖子有超过 560 条回复，里面大多数是机器人在为自己的主人，推销相关的安全产品

顺藤摸瓜之后，这位开发者火速冲到 LiteLLM 的 GitHub 仓库提交了问题报告，试图给整个开源社区拉响警报。

但他没想到的是，102 秒内，黑客动用了手里的开发者僵尸账号网络，往帖子下面灌了 88 条无关评论，试图把真正的警告淹没在垃圾信息里。

紧接着，黑客直接登录了窃取来的 LiteLLM 维护者账号，用管理员权限强行关闭了讨论区。

上下滑动查看更多内容

截至目前，恶意包已被官方隔离，LiteLLM 团队紧急重置了所有密钥。但在那失去防备的 3 个小时里，没有人知道，已经有多少开发者的密钥流进了暗网。

开源生态的安全，有时是「皇帝的新衣」

这件事值得谈的不只是 LiteLLM 本身，而是它暴露出的整个生态的结构性溃败。

在软件开发领域，「不要重复造轮子」几乎是圣经级别的准则。有现成的库就用现成的，把精力放在真正要做的事情上。这套逻辑让整个行业的效率飞速提升。

但代价是什么？

随便打开一个 Python 项目，requirements.txt 里几十上百个依赖。每个依赖又有自己的依赖。真正的「依赖树」深达七八层，横跨几百个包，维护者分布在地球的各个角落，有的是大厂工程师，有的是在读学生，有的可能三年没登录过 GitHub 了。

你以为你在信任一个包。你实际在信任一整棵你看不见全貌的树上的每一片叶子。

这棵树上任何一个节点被攻陷，危险都会顺着依赖关系一路流到你的机器上。而你对此的防御手段是什么？看一眼包名，确认下载量够大，然后按回车。

开源虽然公开透明，但不一定等于安全，他需要大量精力去审核

开源安全的底层假设是「足够多的眼睛在看，所有的 bug 都无处可藏」。但 2026 年的现实是，不是看的眼睛不够多，而是没有人再用眼睛看了。

PyPI 没有强制的包签名验证机制，npm 的 provenance 功能普及率极低。大多数包管理器对「这个版本是不是真的由官方发布的」这个最基本的问题，至今无法给出可靠的回答。

安全基础设施还停留在「Linus 定律」的田园时代。而 AI 带来的新用户，正在以每月数百万的速度涌入。

门是 AI 帮你推开的，门后面可能有坑

现在，事情变得更魔幻了。AI 正在以前所未有的速度放大这个信任黑洞。

以前装一个包，好歹是开发者自己查了文档、比较了方案之后做出的选择。现在的流程是：打开 Cursor，告诉 AI「帮我做个 XX 功能」。AI 写好代码，发现报错了，然后补一句 pip install litellm，终端开始跑，你看了一眼，按下回车。

就这么一下。

你不知道它装了什么。你不知道它为什么装这个。你只知道 AI 说这样能修好，你就确认了。

更魔幻的是，这种行为模式已经不限于开发者了。连安装 OpenClaw 这种极客项目，需要敲终端命令行，都出现在了微信官方应用里，大大方方写着 npx -y。「人人都能成为开发者」这句话翻译一下就是：人人都能成为供应链攻击的受害者。

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

上下滑动查看更多内容

Karpathy 也对这件事发了评论。他说自己越来越不愿意用第三方依赖，开始倾向于让 LLM 直接把功能代码生成出来，自己造，不装黑盒。

这个思路在个人层面完全说得通。但放到行业层面，它是一个「何不食肉糜」式的建议。

能让 LLM 从零生成一套完整实现的人，本来就不是供应链攻击的主要受害群体。真正的受害者是那些连 pip install 装了什么都看不懂的新用户，是被 AI 编程工具带进来的、对「依赖」这个概念毫无认知的百万新开发者。

告诉他们「你应该自己写代码而不是装依赖」，约等于告诉一个刚拿到驾照的人「你应该自己造车而不是买车，因为买来的车可能有缺陷」。

门是 AI 帮你推开的，现在又告诉你，门后面可能有坑，你最好自己造一扇新的。

问题的根源不在于个人选择，而在于整个生态的信任基础设施已经跟不上 AI 带来的用户增长速度。这个剪刀差，才是 LiteLLM 事件真正让人不安的地方。

整个文件系统都是攻击面

有网友说，这次的黑客只想着偷 API Key，格局还是小了。

更高级的玩法是悄悄污染你的 ~/.claude 目录、AI Agent 的 skills 文件夹，甚至你每天早上让 AI 帮你处理的那份 PDF 简报。整个文件系统都是攻击面。任何可能进入 AI 上下文的文件，都可能是一个攻击载体。因为 AI 不区分「可信输入」和「不可信输入」，对它来说，一切都是上下文。