连Karpathy都怕了！9千万级AI包被投毒，竟靠黑客写出bug救命

新智元报道

编辑：元宇

【新智元导读】一次只持续了不到1小时的投毒事件，撕开了AI基础设施「信任链」的致命裂缝。更魔幻的是，全行业逃过一劫，居然靠黑客自己写出bug。

刚刚，科技界经历了一场惊心动魄的「供应链投毒」危机。

3月24日上午，一个普通的版本更新LiteLLM 1.82.8，出现在PyPI上。

全球数百万开发者的终端，每天都在自动拉取这类更新，没有人注意到这个版本里藏着一段精心设计的恶意代码：

只要你执行一句pip install litellm，你机器上的SSH密钥、云服务凭证、数据库密码、加密货币钱包……会在几秒内被加密打包，发往一个伪装成官方的服务器。

然后，如果你的机器连着Kubernetes集群，恶意代码会自动横向扩散，在每个节点上植入后门。

LiteLLM，是当下AI应用开发中最核心的基础设施之一。它的开源包全球月下载量9700万。

但这次，这根管道却差点被人从内部凿穿，而且之所以逃过一劫，纯属意外。

攻击者自己的代码里有个bug，导致目标机器直接崩溃。如果没有这个bug，没人知道这次「投毒」还要扩散多久。

目睹这一幕，Andrej Karpathy深夜发文，直呼这是「软件惊魂」。

Karpathy帖子中所列的「窃取清单」堪比「灾难现场」：

AWS/GCP/Azure 凭据、Kubernetes配置、CI/CD 机密、数据库密码、SSH 密钥……

「惊魂」过后，Karpathy说了一句可能改变整个行业开发范式的话：

「我越来越抗拒依赖了。」

pip install

然后你的一切都没了

这不是一次普通的漏洞告警，只要你在终端里敲下这句看似人畜无害的pip install litellm，你的整台机器就会瞬间对攻击者彻底敞开大门。

根据安全分析，这次投毒不是简单地偷几个密码，而是对整台机器和整个集群的「全面洗劫」。

攻击者的窃取清单几乎覆盖了开发者最核心的一切：

• SSH私钥和配置

• AWS/GCP/Azure凭证

• Kubernetes配置和Token

• .env中的API Key

• git凭证

• 数据库密码

• shell历史记录

• SSL私钥

• CI/CD机密

• 加密货币钱包文件

• 环境变量中的敏感信息

更可怕的是，LiteLLM根本不是一个冷门工具。

作为连接各大语言模型提供商的关键中间件，它是名副其实的AI应用层「水电煤」，拥有每个月高达9700万次的下载量！

很多项目用它统一连接OpenAI、Anthropic、Google、Azure等多家模型提供商。

许多Agent框架、MCP Server、LLM编排工具，也会把它作为底层依赖引入。

这让这次投毒的影响，升级到了整条AI依赖链被撕开一道口子。

即使你根本不知道什么是LiteLLM，只要你执行了pip install dspy（它依赖litellm>=1.64.0），或者安装了其他任何依赖该包的大型AI项目，你都会作为传递依赖的受害者中招。

一次投毒，顺着错综复杂的依赖树，瞬间就会辐射到无数AI项目中。

这就是为什么Karpathy会直接把它定义为「软件界的恐怖故事」。

一次靠黑客「代码写太烂」才暴露的史诗级漏洞

你可能会想，既然影响这么大，那安全公司一定第一时间拉响了警报吧？

但事实的真相有点荒诞和讽刺。

最早发现异常的，是Callum McMahon团队的工程师。

当时，他们在Cursor里使用一个MCP插件，而这个插件会把LiteLLM作为传递依赖拉进来。

安装到被投毒的LiteLLM1.82.8之后，机器突然开始异常：内存被疯狂吃满，最后直接崩溃。

后来追进去才发现，问题出在一个.pth文件上。

对很多Python开发者来说，.pth文件平时几乎没有存在感。

但正因这样，它可以在Python解释器启动时自动执行代码。攻击者就在这里塞进了恶意启动器。

按原本设计，它会悄悄拉起子进程，执行后续窃密和外传逻辑。

结果它写砸了。

因为子进程本身也会再次触发同一个.pth文件，于是每个新进程都会再生出新进程，进入指数级自我复制，最后演变成一个fork bomb，把机器资源迅速吃光。

也就是说，这次攻击之所以暴露，只是因为它自己把自己玩炸了。

如果攻击者不是靠vibe coding搞出了这个乌龙，这次如此隐蔽的后门，极可能会在全网潜伏数周甚至数月而不被察觉。

全行业的安全防线竟然靠的是黑客写了个bug，整个生态的安全检测机制，在这一刻形同虚设。

这也是整件事最让人后怕的地方。

一场精心策划的「 供应链投毒」

从攻击手法的精密程度来看，这是一场有组织的「供应链投毒」。

首先，攻击者不知通过何种手段攻破了维护者的PyPI账户，直接绕过了官方的CI/CD发布流程，把带有后门的v1.82.7和v1.82.8版本强行上传到了PyPI仓库。

在LiteLLM的GitHub源码仓库中，你甚至找不到对应的tag或release记录。

其次，攻击载荷分为极其专业的三段式：

第一阶段，是精准的大范围「收集」；

第二阶段，是用内置的4096位RSA公钥配合AES-256-CBC进行高强度「加密」，并外传到一个极具迷惑性的假域名（models.litellm.cloud）；

第三阶段最致命，如果环境中存在Kubernetes的凭证，它会直接「横向移动」，读取集群中所有命名空间下的全部Secret，并在所有节点创建特权Pod，植入持久化后门。

LiteLLM 1.82.8的恶意litellm_init.pth文件，在Python解释器启动阶段被自动触发，进而执行三阶段payload攻击

最令人毛骨悚然的一个细节发生在事发后：

当社区试图在GitHub issue中讨论此事时，该issue被所有者直接以「not planned」关闭，随后被数百个机器人账号疯狂刷屏淹没。

维护者的账号和开发环境显然已被全面接管，攻击者正在系统性地掩盖痕迹。

目前，LiteLLM官方已经介入，怀疑此次事件与更大范围的Trivy安全事件有关（疑似使用被盗凭证），并紧急联系了Google Mandiant安全团队进行取证。

所幸的是，官方Docker镜像的用户因固定了版本而免遭一劫。

但这套完整的APT（高级持续性威胁）手法，已经宣告了「战争」的升级。

Karpathy的「反依赖宣言」

AI开发范式要变了

这场灾难，正在深刻改变硅谷顶层技术精英对软件工程的底层认知。

传统的软件工程观念一直教导我们：不要重复造轮子。依赖是构建宏大金字塔的坚实砖块。

但在这次事件后，Karpathy在推文中抛出了他的「反依赖宣言」：

这也是为什么我越来越抗拒依赖，更倾向于在功能足够简单、而且确实可行的时候，直接用LLM去「顺」一段功能来用。

从「依赖是砖块」到「依赖是定时炸弹」，这不仅仅是情绪的发泄，更是AI时代开发范式的重大转折。

每次执行pip install，你都在整棵依赖树深不可测的某一环，引入了致命的未知风险。

当大模型已经强大到能够直接生成和替换第三方依赖的底层逻辑时，「少依赖」将不再是代码洁癖，而会成为核心的安全策略。

这其中还隐藏着一个极具讽刺意味的闭环：

Callum之所以中招，是因为使用了AI编码工具Cursor，通过MCP插件引入了AI中间件litellm。

AI工具链自身，竟然成了最大的攻击面。

AI正在飞速创造解决问题的新范式，但同时也在创造前所未有的新漏洞。

9700万次下载背后的「信任危机」

LiteLLM官方已经在做止血动作：

下架受污染版本；轮换维护者凭证；建立新的授权维护者；联系Mandiant做取证分析；提示用户排查受影响版本、查找IoC、轮换所有凭证。

https://docs.litellm.ai/blog/security-update-march-2026

虽然，LiteLLM事件以不到1小时的「闹剧」收场，受污染版本已被撤回，凭证也已轮换，但真正令人不安的是，这次事件之所以没有演变成更大规模的静默灾难，不是靠安全体系发现了它，而是因为黑客自己出错。

9700万的月下载量，意味着全行业进行了9700万次「信任赌博」。

这次「投毒事件」暴露出AI基础设施中开源供应链的信任模型，也可能是极其脆弱的：

你以为你信任的是成千上万行经过审查的开源代码，但实际上，你信任的仅仅是某个远在天边的包维护者没有把他的PyPI账号密码搞丢，或者他的电脑没有中木马。

这种系统性的安全风险，对于过度依赖开源的AI生态无疑是一记重锤。

如果AI开发者和企业大量依赖PyPI等开源包，而基础设施安全又仅仅寄托在「上游没有被黑」这种虚幻的假设上，类似危险的重演，可能只是时间问题。

LiteLLM只是一个开始，谁也无法回答那个最让人不安的问题：

下一个被投毒的包，会是哪个？

参考资料：

https://x.com/karpathy/status/2036487306585268612?s=20%20

https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/