⚠ 高危预警
供应链攻击 · PyPI · 2026-03-24

litellm PyPI 供应链攻击分析

恶意版本通过 .pth 文件在每次 Python 进程启动时自动执行，窃取凭证并向 Kubernetes 集群横向扩散。

发现时间：2026-03-24 10:52 UTC 受影响版本已下架
威胁等级 CRITICAL 凭证窃取 + 持久化后门 + Kubernetes 集群扩散，影响范围极广。
litellm 是什么

LiteLLM 是一个开源的 Python SDK 与 AI 网关，允许开发者以统一的 OpenAI 格式调用 100+ 个大语言模型（LLM）服务。

无论后端是 OpenAI、Anthropic、Google Vertex AI、AWS Bedrock、Azure、HuggingFace，还是本地部署的 vLLM、NVIDIA NIM，开发者只需调用同一套 API 接口，LiteLLM 负责在底层完成协议转换、路由分发和统一错误处理。

它支持 /chat/completions、/embeddings、/images、/audio、/batches 等主流端点，并提供负载均衡、重试、可观测性回调、多租户成本追踪等企业级功能，P95 延迟在 1000 RPS 压力下仅为 8ms。

🐍
Python SDK 模式
直接作为库集成到应用代码中，内置路由逻辑、负载均衡与可观测性回调，适合轻量级服务和快速原型开发。
🌐
AI Gateway 代理模式
作为中心化代理服务部署，提供认证、虚拟密钥管理、多租户成本统计与管理员仪表板，适合企业级统一 LLM 接入层。
▍使用范围极广——谁在用 litellm？
🤖 AI 应用开发者
快速接入多家模型，一套代码兼容全部主流 LLM
🏢 企业 AI 平台团队
统一管理内部各部门对 LLM 的访问、配额与费用
🔌 IDE 插件与 MCP 工具
Cursor 等 AI 编程工具通过 litellm 作为模型中间层（本次攻击即由此传播）
☁️ 云原生与 Kubernetes 环境
容器化部署，天然融入现代 DevOps 工作流
▍GitHub & PyPI 数据
40.3k
⭐ GitHub Stars
96M+
📦 PyPI 月下载量
21.6M
📦 PyPI 周下载量
100+
🤖 支持 LLM 供应商

数据来源：github.com/BerriAI/litellm & pypistats.org · 2026-03-24

⚠️ 攻击影响面评估：正是由于 litellm 在 AI 生态中的广泛使用（月下载量近亿次），此次供应链攻击的潜在受害者规模极为庞大。攻击者选择 litellm 作为投毒目标，体现了其对高价值供应链节点的精准选择。
事件时间线
10:52 UTC（北京时间3月24日18:52）
litellm 1.82.8 发布至 PyPI，包含恶意 litellm_init.pth 文件。该版本未在 GitHub 上发布对应 Release，绕过了正常的发布流程。
12:30 UTC（北京时间3月24日20:30）
确认 1.82.7 同样已被篡改，受影响范围扩大。
13:03 UTC（北京时间3月24日21:03）
GitHub 上的公开 Issue 被仓库所有者以"not planned"关闭，并遭到机器人刷屏。 litellm 作者账号疑似已被全面入侵。
20:15 UTC（北京时间3月25日04:15）
受感染版本已从 PyPI 下架，包维护者正处理后续影响。FutureSearch 平台用户数据未受影响。
攻击概述
📦
投毒手法
攻击者将恶意 litellm_init.pth 文件植入 PyPI 包内。.pth 文件是 Python 的路径配置文件，会在每次 Python 解释器启动时自动执行，无需任何显式导入。
💥
意外触发的"叉子炸弹"
恶意 .pth 通过 subprocess.Popen 生成子 Python 进程。由于 .pth 文件在每次解释器启动时都会触发，导致进程指数级增殖，产生叉子炸弹，最终导致机器崩溃——这是恶意软件自身的 bug。
🔗
传播路径
该恶意包在 Cursor IDE 加载某 MCP 插件时以间接依赖（transitive dependency）的方式被引入，说明攻击者利用了复杂依赖链来扩大感染面。
恶意软件行为分析
01
COLLECT
阶段一：本地信息收集
  • SSH 私钥文件
  • .env 环境变量文件
  • AWS / GCP / Azure 云服务商凭证
  • Kubernetes 配置文件（kubeconfig）
  • 数据库密码及连接字符串
  • .gitconfig、Shell 历史记录
  • 加密货币钱包文件及密钥
  • 当前进程的环境变量快照
  • 云平台 IMDS 元数据端点、容器凭证接口
02
EXFIL
阶段二：数据加密与外泄
  • 使用硬编码的 4096-bit RSA 公钥结合 AES-256-CBC 对收集到的数据进行加密
  • 将加密数据打包为 tar 归档文件
  • 通过 HTTP POST 发送至 https://models.litellm.cloud/（非 litellm 官方基础设施）
C2 服务器地址（非官方域名）
POST https://models.litellm.cloud/
Content-Type: application/octet-stream

[AES-256-CBC 加密数据 + RSA-4096 封装密钥]
03
PERSIST
阶段三：横向移动与持久化
  • 检测 Kubernetes Service Account Token，若存在则读取所有命名空间的 Secret
  • 在 kube-system 中每个节点上创建特权 alpine:latest Pod（命名规则：node-setup-*）
  • Pod 挂载宿主机根文件系统，安装持久化后门至 /root/.config/sysmon/sysmon.py
  • 注册 systemd 用户服务 sysmon.service 实现开机自启
  • 本地机器同样部署后门至 ~/.config/sysmon/sysmon.py
排查与应急响应
1
确认是否受影响
检查是否在 2026-03-24 之后安装或升级了 litellm，并运行以下命令确认版本：
pip show litellm
同时检查 uv 缓存、CI/CD 环境及所有虚拟环境中的 litellm 版本。
2
删除软件包并清除缓存
从受影响环境中卸载 litellm 1.82.8，并清除包管理器缓存以防止从缓存重新安装：
rm -rf ~/.cache/uv  或  pip cache purge
3
检查持久化后门
检查本地是否存在以下路径：
~/.config/sysmon/sysmon.py
~/.config/systemd/user/sysmon.service
如使用 Kubernetes，审计 kube-system 命名空间中名称匹配 node-setup-* 的 Pod，并检查集群 Secret 是否存在未授权访问记录。
4
轮换所有凭证
假定受影响机器上的全部凭证已泄露，立即轮换：SSH 密钥、云服务商凭证（GCP / AWS / Azure）、Kubernetes 配置、.env 文件中的 API 密钥，以及数据库密码。
FutureSearch 如何发现此攻击

FutureSearch 团队在开发其产品时，通过 litellm 接入多个模型供应商的 API。在加载 Cursor IDE 中的某个 MCP 插件时，工程师注意到异常——由于恶意 .pth 文件触发的叉子炸弹效应，机器直接崩溃，引起了研究人员的高度警惕。

随后，工程师借助 Claude Code 进行根因分析，迅速定位了 litellm_init.pth 文件中的恶意代码，并第一时间向 PyPI 官方（security@pypi.org）及 litellm 维护者举报。

FutureSearch 表示，此次事件中其平台损失极小，无用户数据泄露。该事件在社区以 litellm Issue #24512 持续追踪。

供应链安全防御建议
🔒
锁定依赖版本
使用 pip-compile、uv lock 或 poetry.lock 锁定直接依赖和间接依赖的精确版本哈希，避免自动升级到恶意版本。
🧐
审计间接依赖
本次攻击通过间接依赖传播，仅审计直接依赖是不够的。定期使用 pip-audit 或 GitHub Dependabot 扫描全量依赖树。
🏗️
隔离构建环境
CI/CD 流水线应在无敏感凭证的隔离容器中运行，避免 SSH 密钥、云凭证挂载到构建环境，降低凭证被盗的爆炸半径。
📡
监控异常进程与网络
检测 subprocess.Popen 等异常子进程创建行为及对未知外部地址的 HTTPS POST 请求；部署 EBPF 或 Falco 等运行时安全工具。
🛡️
Kubernetes 最小权限
限制 Service Account 的 RBAC 权限，禁止默认挂载 Token，对 kube-system 命名空间的 Pod 创建操作实施严格审计策略。
🔄
凭证定期轮换
即便未发现感染迹象，也应建立凭证定期自动轮换机制，将凭证泄露的潜在危害窗口降至最低。