危险！你的号池在将所有 API KEY 上传！LiteLLM 1.82.7/1.82.8 供应链攻击详解

文章目录

你的 API 号池环境里，可能躺着一个定时炸弹。

2026 年 3 月 24 日，PyPI 官方紧急下架了 LiteLLM 的两个版本——1.82.7 和 1.82.8。

不是 bug，而是这两个版本被植入了窃取凭证的木马。Wiz、Datadog Security Labs、Kaspersky、Snyk 等主流安全厂商全部在 48 小时内发布了警报。

这件事值得认真对待，因为它暴露了高价值 API 代理服务的安全脆弱性。

LiteLLM 是什么，和 New API 有什么区别

Claude Code 频繁被封，逼着大家不得不在各大模型间来回切换。我们接触到的付费 API 系统，大多采用 New API 项目搭建。

New API 是一个开源项目，截至 2026-03-29 在 GitHub 上 Star 23.7k。

https://github.com/QuantumNous/new-api

New API 的典型用户是搭建 AI 中转站的人，提供多渠道管理、余额统计、自动签到、额度监控这类运营能力，本质是一个分发系统而不是调用封装。

LiteLLM 是一个 LLM 调用封装库，核心价值是用同一套代码调用 100+ 种 LLM 提供商的 API——OpenAI、Claude、Gemini、Azure OpenAI、本地 vLLM、Ollama……它既可以作为 Python SDK 在代码里调用，也可以部署为 proxy 服务充当 AI Gateway。

https://github.com/BerriAI/litellm

截至 2026-03-29，LiteLLM 在 GitHub 上的 Star 为 41.4k。

• LiteLLM = 你写的代码去调各种 API 的胶水层
• New API = 你搭一个平台让别人来调你的接口

两者定位不同，但都涉及 API key 的管理。

LiteLLM 事件也格外值得 New API 用户警惕：你管理的 key 越多，攻击者越感兴趣。

发生了什么

LiteLLM 是一个流行的 Python 库，被大量企业用作 AI Gateway 的核心组件。攻击者获取了维护者的 PyPI 账号后，在 3 月 24 日上传了两个恶意版本：

• v1.82.7：在 proxy_server.py 中植入了恶意 payload
• v1.82.8：引入了 litellm_init.pth 文件，利用 Python 的 .pth 机制实现持久化和隐蔽执行

这些版本没有在 GitHub 上留下痕迹。恶意代码只存在于 PyPI 分发的包中。很多人即使查看了源码仓库，也不会发现异常。

恶意代码会窃取环境中几乎所有值钱的东西：

• 云服务商凭证（AWS、GCP、Azure）
• CI/CD secrets（GitHub Actions、GitLab CI 环境变量）
• API keys（OpenAI、Anthropic、各种 LLM 渠道）
• Slack、Discord 等通信平台 token

数据会被发送到攻击者控制的域名。整个过程静默运行，除非主动抓包检查出站流量，否则几乎无感知。

LiteLLM 的主要用户是企业，它是部署 AI Gateway 的首选工具之一。那些部署了 LiteLLM proxy 的服务器，天然持有 大量 API key 和云凭证。 这正是攻击者最想要的东西。

攻击者是谁

这轮攻击被归属到 TeamPCP——一个专门针对开源供应链的攻击组织。他们此前已经用类似手法攻击过 Trivy（容器安全扫描工具）和 Checkmarx 等项目。具体到 LiteLLM，入口是通过 Trivy 的代码扫描服务被攻破，进而拿到了 LiteLLM 维护者的 PyPI 凭证。

这是一个教科书级别的供应链攻击链：

攻击一个安全工具 → 获取通往主项目的凭证 → 在 PyPI 投毒 → 影响所有下游用户。

你需要做什么

如果你用过 LiteLLM 1.82.7 或 1.82.8：

1. 立即卸载：pip uninstall litellm
2. 升级到安全版本：pip install litellm>=1.82.9
3. 轮换所有密钥：你在运行 LiteLLM 的环境中所接触过的所有 API key、云凭证，全部当作已泄露处理。
4. 检查网络流量：看有没有发往陌生域名的出站请求。

Docker 部署的 LiteLLM 受影响吗？

曾老师让龙虾帮忙查了下服务器上的 LiteLLM Docker 容器：

龙虾说，曾老师部署的官方 Docker 镜像 不受影响。

官方 LiteLLM Proxy Docker 镜像走的是独立构建路径，不依赖那两个被污染的 PyPI 包版本。这是官方在安全通告中明确说明的。

龙虾发现曾老师使用的是 latest ，顺便批评了曾老师，让曾老师改为固定版本，龙虾的原话如下。

以 /data/docker/compose/litellm 的配置为例：

1image: litellm/litellm:latest

latest 意味着每次拉取都会拿到最新镜像，版本完全不可控。虽然这次 Docker 镜像本身没问题，但未来任何新的恶意版本如果针对 Docker 构建路径，latest 就会自动中招。正确做法是锁定到一个固定的版本标签或 digest，例如：

1image: litellm/litellm@sha256:9a03bac8b54f6e8b25359e713740d40fe5caf5ca88b5baa0dfcd78f95a95eeb7

或者用语义化版本：

1image: litellm/litellm:1.82.9

总结一句话： 官方 Docker 镜像路线在这次事件中是安全的，但曾老师你用了 latest 就等于把这个安全边界交了出去。趁这次机会改成固定版本，是值得做的改进。

真正值得想的

这次事件最让人不安的地方，不是攻击有多高明，而是我们默认信任了 pip install 的产出物。

开源生态建立在 「源码公开、人人可审查」 的假设上，但 PyPI 分发的包和 GitHub 上的源码完全可以是两回事。只要维护者账号被拿下，这个假设就不成立了。

LiteLLM 的 GitHub 仓库里没有恶意代码，但 47,000+ 次下载量的恶意版本已经在 PyPI 上躺了好几天。

你的 CI/CD 流水线里有多少依赖？每次 pip install 的时候，你真的验证过装的是什么吗？

参考来源

• LiteLLM 官方安全公告：https://docs.litellm.ai/blog/security-update-march-2026
• Wiz 安全分析：https://www.wiz.io/blog/threes-a-crowd-teampcp-trojanizes-litellm-in-continuation-of-campaign
• GitHub Issue #24518：https://github.com/BerriAI/litellm/issues/24518
• Endor Labs 分析：https://securityaffairs.com/189948/hacking/malicious-litellm-versions-linked-to-teampcp-supply-chain-attack.html
• Orca Security：https://orca.security/resources/blog/litellm-supply-chain-attack-malware/
• Snyk：https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/
• Datadog Security Labs：https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/
• Kaspersky：https://www.kaspersky.com/blog/critical-supply-chain-attack-trivy-litellm-checkmarx-teampcp/55510/
• FutureSearch：https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/