LiteLLM PyPI 包被植入恶意代码，请停止更新：pip install litellm

🔥 紧急预警：如果你的终端里曾经敲下过 pip install litellm，请立即放下手头的工作，仔细阅读本文。2026年3月，AI开源生态遭遇了一场精心策划的“供应链核爆”——全球下载量超千万的LLM统一接口库 LiteLLM 被发现官方PyPI包中被植入了恶意代码。这不是一次普通的漏洞，而是一场针对AI开发者、企业Agent系统甚至云上生产环境的定向猎杀。

先上结论：你现在需要做什么？

在展开深度分析之前，请先完成以下三件事，这关乎你的API密钥安全、服务器权限，甚至是企业的合规底线：

操作步骤	指令/动作	紧急程度
1. 立即停止	暂停所有 pip install litellm --upgrade 操作	🔴 紧急
2. 环境自查	执行 pip show litellm 或检查 pip list，确认已安装版本	🟠 高危
3. 密钥轮换	若近期安装/更新过LiteLLM，立即轮换所有AI厂商API Key（OpenAI、Anthropic等）	🟡 强烈建议

---

什么是LiteLLM库？为什么它值得攻击者“投毒”？

对于刚接触AI开发的同学，可能还不清楚LiteLLM是什么，以及为什么一个Python包的“中毒”事件能引发整个AI圈的地震。这里我们先花2分钟快速科普：

LiteLLM 是一个“大一统”的LLM网关库。

简单来说，如果你想让你的应用同时调用OpenAI、Azure、Anthropic（Claude）、Google Gemini、Cohere等几十种大模型，原生写法需要为每个厂商写一套SDK调用代码，极其繁琐。而LiteLLM的作用就是——用一个统一的接口，调用所有模型。

# 使用LiteLLM前：你需要为每个模型写不同的调用代码
# 使用LiteLLM后：只需更换model参数
import litellm

# 调用OpenAI
response = litellm.completion(model="gpt-4", messages=[{"role": "user", "content": "Hello"}])

# 调用Claude（仅需换model名）
response = litellm.completion(model="claude-3", messages=[{"role": "user", "content": "Hello"}])

# 调用Gemini（同样写法）
response = litellm.completion(model="gemini-pro", messages=[{"role": "user", "content": "Hello"}])

正是这种“化繁为简”的能力，让LiteLLM成为AI应用开发中的基础设施级依赖。据统计，超过3万个GitHub仓库、数百个AI Agent框架（如AutoGen、LangFlow等）都将其作为核心组件。攻击者盯上它，相当于在AI世界的“水电管道”里动了手脚——一次投毒，波及全行业。

LiteLLM的下载、安装与正常配置

在了解事件的严重性之前，我们先回顾一下LiteLLM的正常安装流程，以便你对照排查：

1. 安装方式

# 标准安装
pip install litellm

# 如需代理能力，安装完整版
pip install 'litellm[proxy]'

2. 基本配置
安装完成后，通常通过环境变量设置API密钥：

export OPENAI_API_KEY="sk-xxx"
export ANTHROPIC_API_KEY="ant-xxx"

3. 启动代理服务

litellm --model gpt-4 --port 8000

然而，正是这套看似标准的流程，如今成为了恶意代码的传播通道。 攻击者将恶意代码伪装后注入官方PyPI包，开发者一旦执行pip install，恶意代码便随正常功能一同潜入系统。

---

接下来，本文将深度拆解本次攻击的技术细节、真实影响范围，以及攻击者TeamPCP的完整攻击链，并为你提供一套可落地的自查与应急方案。请跟随目录继续阅读：

🚨 紧急预警：LiteLLM PyPI 包被植入恶意代码，请立即停止更新！

Software Horror —— 这是大神 Andrej Karpathy 对这起事件的定性。

---

一、事件概述：发生了什么

2026年3月24日上午 8:30 UTC，LiteLLM 的两个恶意版本（1.82.7 和 1.82.8）被发布到 PyPI。

这两个版本在 GitHub 上没有对应的 tag 或 release，是攻击者绕过正常发布流程，直接上传到 PyPI 的 。

根据 Wiz 的分析，36% 的云环境中存在 LiteLLM 。换句话说，全球超过三分之一的云环境都可能暴露在这次攻击的射程之内。

恶意版本大约在 11:25 UTC 被 PyPI 隔离，暴露窗口约 3 小时。LiteLLM 每天大约有 340 万次下载，3 小时内可能有数十万次安装 。

⚠️ 危害程度：全盘失守

只要你执行了 pip install litellm，你机器上的以下敏感信息将被全部打包加密，发送到黑客服务器：

凭证类型	具体路径/位置
SSH 密钥	~/.ssh/
云凭证	AWS/GCP/Azure 配置文件
Kubernetes 配置	~/.kube/config
Git 凭证	全局配置与凭证助手
环境变量	所有 API Key、数据库密码
Shell 历史	~/.bash_history, ~/.zsh_history
加密货币钱包	各类钱包文件
SSL 私钥	证书文件
CI/CD 密钥	Jenkins、GitHub Actions 等
数据库密码	连接字符串

NVIDIA 机器人研究主管 Jim Fan 称： “这是纯粹的噩梦燃料。过去的身份盗窃，跟 vibe agent 能干的事比起来根本不值一提。”

---

二、攻击技术细节深度解析

2.1 无需 import 就中招：.pth 文件的致命陷阱

这次攻击用了一个大多数 Python 开发者恐怕都没听说过的机制：.pth 文件。

• 一般恶意包：需要你 import 它才能触发
• .pth 文件：Python 的 site 模块在解释器启动时自动加载

只要这个包装在你的环境里，你跑任何 Python 脚本，恶意代码都会自动执行。

不需要 import，不需要调用，甚至不需要你的代码跟 LiteLLM 有任何关系！

类比：你在小区快递柜取了个包裹，结果这个包裹会在你每次开家门的时候，自动把你家钥匙复制一份寄出去。

这个机制在 MITRE ATT&CK 框架中已经有了自己的编号：T1546.018（Python Startup Hooks） 。

2.2 两个版本的攻击差异

版本	攻击方式	触发条件	危害范围
1.82.7	代码注入 proxy_server.py 第 128 行	导入 litellm.proxy.proxy_server	使用代理模块的用户
1.82.8	.pth 文件 litellm_init.pth	任何 Python 进程启动	所有 Python 用户

两个版本之间只隔了 13 分钟。攻击者在实时迭代 。

2.3 三级火箭：恶意代码的精密设计

🚀 第一阶段：扫荡（凭证收割）

一个 332 行的凭证收割脚本，系统性地扫描：

# 恶意代码扫描的部分目标路径示例
~/.ssh/id_rsa                    # SSH 私钥
~/.aws/credentials               # AWS 凭证
~/.config/gcloud/                # GCP 配置
~/.kube/config                   # K8s 配置
~/.bash_history                 # Shell 历史
.env                            # 环境变量文件
/etc/shadow                     # 密码哈希文件

甚至自己实现了一套完整的 AWS SigV4 签名流程，去调 Secrets Manager 和 SSM Parameter Store 的 API 来偷取更多密钥 。

🚀 第二阶段：加密外传

# 数据打包流程
1. 收集数据 -> tpcp.tar.gz
2. AES-256 加密
3. 4096 位 RSA 公钥加密会话密钥
4. POST 到 models.litellm.cloud（攻击者控制的域名）

注意：models.litellm.cloud 这个域名看着像 LiteLLM 的官方基础设施，其实是攻击者在 3 月 23 日刚注册的 。

🚀 第三阶段：横向扩散

如果发现机器上有 Kubernetes 的 service account token：

1. 读取集群内所有 namespace 的 secrets
2. 在每个节点上部署特权 Pod（node-setup-{节点名}）
3. 挂载宿主机的整个文件系统
4. 安装持久化后门

同时还会在本地装一个 systemd 服务，伪装成「System Telemetry Service」，每 50 分钟从 checkmarx.zone 拉取新的指令 。

2.4 戏剧性发现：黑客的 bug 救了所有人

这个攻击差点就完美了。

发现过程：FutureSearch 的研究员 Callum McMahon 在 Cursor 里用一个 MCP 插件，这个插件把 LiteLLM 作为传递依赖拉了进来。LiteLLM 1.82.8 一装上，他的机器瞬间内存耗尽，直接崩溃 。

原因：.pth 文件的 launcher 用 subprocess.Popen 启动了一个子 Python 进程来执行恶意代码。但问题是，子进程启动时又会加载 .pth 文件，然后又启动一个子进程……

经典的 fork bomb。指数级进程爆炸。

Karpathy 的讽刺：“如果攻击者没有在这次攻击中「vibe code」的话，这个恶意代码可能会在不被发现的情况下存活好几天甚至好几周。”

---

三、影响范围：不只是 LiteLLM

3.1 依赖树传染

LiteLLM 本身 9700 万月下载量已经够吓人了。但更让人后背发凉的是，它其实是很多主流 AI 框架的底层依赖。

Karpathy 警告：

“更糟糕的是，这个污染会扩散到任何依赖 LiteLLM 的项目。比如你执行 pip install dspy（它依赖 litellm>=1.64.0），你也会中招。其他任何依赖 LiteLLM 的大型项目同理。”

3.2 紧急修复的项目

3 月 24 日当天，以下项目紧急提交了安全修复 PR ：

• DSPy - 微软的 AI 编程框架
• MLflow - 机器学习生命周期管理
• CrewAI - 多 Agent 编排框架
• OpenHands - AI 软件开发助手
• Prodigy - 爆款 NLP 标注工具

你以为你装的是一个 AI 框架，实际上你把整台机器的凭证都交出去了。

---

四、攻击链复盘：TeamPCP 的连环猎杀

而 TeamPCP 这个名字，最近一个月在安全圈已经出现了太多次了。

根据 Snyk 的分析，这已经是他们从去年 12 月开始的系列攻击的第九阶段 ：

日期	目标	攻击手段	窃取凭证用途
2月28日	Trivy	pull_request_target 漏洞	获取 Aqua 组织权限
3月19日	Trivy (再次)	后门二进制文件	CI/CD 凭证
3月20日	NPM 生态	CanisterWorm 蠕虫	自我传播
3月22-23日	Checkmarx	服务账号沦陷	KICS GitHub Action
3月24日	LiteLLM	偷来的 PyPI token	全面凭证收割

攻击策略：专门挑安全工具下手。漏洞扫描器、代码分析器、LLM 代理……这些工具天生就要跑在高权限环境里，一旦被攻破，拿到的凭证质量极高 。

Snyk 的评价：“你的防守工具，变成了攻击你的武器。”

---

五、SOC 2 认证的讽刺

这件事背后，还有个讽刺的插曲。

LiteLLM 在官网上标注了自己通过了 SOC 2 Type I 认证，而 SOC 2 应该意味着一家公司的安全流程经过了独立审计。

但有人扒出来了：LiteLLM 的 SOC 2 是 Delve 签发的。

Delve，就是那个最近被曝出伪造了 533 份 SOC 2 审计报告的公司 。

9700 万月下载量，零真实审计。 SOC 2 的牌子挂在那里，给了所有人一种「有人替你检查过了」的安全错觉。

瑞士 AI 教授 François Fleuret 质疑：

“Python 生态为什么不在各个层面都做加密签名呢？”

虽然有人回复说包已经签名了，但没用，因为发布者账号本身就被盗了。

签名验证的是「包确实是这个账号发的」，但验证不了「这个账号有没有被控制」。

认证验证的是流程，验证不了代码。合规不等于安全。

---

六、Agent 时代的新恐惧

Jim Fan 提出了一个比凭证盗窃更进一步的担忧：Agent 劫持。

“窃取凭证太明显了，那是菜鸟做的事。它们完全可以把污染扩散到 ~/.claude、**/skills/*，甚至只是你的 Agent 定期读取的一个 PDF。”

想想看：如果恶意代码不去偷你的 SSH 密钥，而是悄悄修改你 Agent 的 skill 文件或者系统提示词呢？

你的 AI Agent 可能就此变成别人的傀儡，用你的身份在所有接入的平台上操作，而你毫不知情。

他管这叫 “de-vibing”：

“用严肃的、经过审计的 Software 1.0 来看管那些奔放的 Software 3.0。Agent 需要壳（shell），而且可能需要很多层嵌套的壳。”

这个观察，其实指向了 AI Agent 安全的一个结构性缺陷：目前「逐项确认每次编辑」和「dangerously-skip-permissions」之间，几乎没有中间地带。

---

七、自查与应急指南

7.1 立即检查命令

# 1. 检查 litellm 版本
pip show litellm 2>/dev/null | grep -i version

# 2. 检查是否存在恶意 .pth 文件
find "$(python3 -c 'import site; print(site.getsitepackages()[0])')" -name "litellm_init.pth"

# 3. 检查持久化后门
ls -la ~/.config/sysmon/sysmon.py
systemctl --user status sysmon.service

# 4. 检查 Kubernetes 中的可疑 Pod
kubectl get pods -A | grep node-setup

7.2 如果确认中招

⚠️ 必须执行以下所有步骤：

步骤	操作内容
1. 隔离	立即断开网络，停止相关服务
2. 删除	移除后门文件和 sysmon 服务
3. 检查 K8s	kubectl get pods -A | grep node-setup，删除可疑 Pod
4. 审计	检查 AWS Secrets Manager 和 SSM Parameter Store 的访问日志
5. 轮换凭证	SSH 密钥、云凭证、API Key、数据库密码、npm token……全部重新生成

7.3 安全版本

目前 LiteLLM 在 PyPI 上已被隔离，恶意版本已删除。

官方建议回退到 v1.82.6 或更早版本 。

# 安全安装命令
pip install litellm==1.82.6

---

八、反思：依赖是原罪？

Karpathy 最后写道 ：

“传统软件工程会告诉你依赖是好事（我们在用砖头盖金字塔），但在我看来这个观念必须被重新审视了。这也是我为什么越来越抵触依赖，更倾向于用 LLM 来「yoink」功能：当功能足够简单且可行时，直接让 AI 帮你把代码写出来。”

“yoink” 的意思：与其 pip install 一个库引入一整棵依赖树和它背后所有不可控的风险，不如让 LLM 直接把你需要的那几十行代码写出来，塞进你自己的项目里。

零依赖，零风险。

Lightning AI 的 Sebastian Raschka 也给了类似思路 ：

“从 GitHub 拉源码快照，用 LLM 辅助做安全审计，然后把审计过的代码直接嵌入自己的项目。”

以前你自己写一个 HTTP 客户端、一个 JSON parser，成本太高了，所以依赖是合理的选择。

但现在呢？LLM 能在几秒钟内帮你生成这些代码，依赖的成本收益比，正在被彻底改写。

Jim Fan 也表示 ：

“大多数人其实用不到 LiteLLM 支持的所有 API，不如按需搭建一个只包含你需要的模型的自定义路由。”

Karpathy 说的是：

“我们构建的整个现代软件大厦，地基是信任。而供应链攻击，动摇的恰恰就是这个地基。”

---

📚 参考链接

• Karpathy 推文
• Jim Fan 推文
• LiteLLM 官方安全公告
• LiteLLM GitHub Issue #24512
• Wiz 技术分析
• Snyk 完整攻击链分析
• Endor Labs 技术报告
• FutureSearch 技术详解
• Hacker News 讨论

---

pip install 这四个字，从来都没有看起来那么无害。

而你的依赖树里藏着什么，可能你自己也不知道。

---

⚠️ 免责声明：本文仅供安全技术研究与风险防范参考，图片来源网络，请读者严格遵守相关法律法规，未经授权不得对他人系统进行任何测试操作。

---