LiteLLM 遭遇史上最严重 AI 供应链攻击

2026 年 3 月 24 日，威胁组织 TeamPCP 通过级联式 CI/CD 攻击链，向 PyPI 发布了两个植入恶意代码的 LiteLLM 版本（v1.82.7 和 v1.82.8），在约 3 小时的暴露窗口内对每月下载量达 9700 万次的关键 AI 基础设施造成重大安全威胁。 攻击载荷包含三阶段凭证窃取器、Kubernetes 横向移动工具包和持久化后门，能够窃取 SSH 密钥、云平台凭证、加密货币钱包和全部 API 密钥。这起事件的讽刺之处在于——LiteLLM 本身就是一个 API 密钥管理网关，攻击者瞄准的正是那个拥有组织中所有 LLM API 密钥访问权限的包。Wiz 研究数据显示 LiteLLM 存在于 36% 的云环境中，Andrej Karpathy 等业界人士指出，攻击的传染效应远超 LiteLLM 本身，任何依赖它的项目（如 DSPy、CrewAI）都面临波及。

一场精心策划的级联攻击：从 Trivy 到 LiteLLM

这并非一次孤立事件，而是 TeamPCP 系统性攻击运动的 第九阶段。攻击链起点在数周之前——2026 年 2 月底，TeamPCP 利用 Aqua Security 旗下 Trivy（知名开源漏洞扫描器）GitHub Actions 环境中的配置错误，窃取了一个特权个人访问令牌（PAT）。

3 月 19 日，攻击者利用这一令牌对 aquasecurity/trivy-action 仓库的 75/76 个版本标签进行了 force-push，将其指向植入恶意代码的 Trivy v0.69.4 版本。3 月 22–23 日，恶意 Trivy v0.69.5 和 v0.69.6 先后被发布至 DockerHub，Checkmarx KICS GitHub Action 的 35 个标签也在此期间被劫持。同时，攻击者在 3 月 23 日通过 Spaceship, Inc. 注册了仿冒域名 litellm[.]cloud。

关键转折发生在 3 月 24 日。LiteLLM 的 CI/CD 流水线中的安全扫描脚本（ci_cd/security_scans.sh）通过 apt 安装 Trivy 时未锁定版本号。被投毒的 Trivy 在 GitHub Actions runner 环境中执行后，窃取了维护者 krrishdholakia（BerriAI CEO Krrish Dholakia）的 PYPI_PUBLISH_PASSWORD 令牌。尽管维护者账号已启用双因素认证，但被盗的 API 令牌完全绕过了 2FA 保护。攻击者随即使用该令牌于 10:39 UTC 和 10:52 UTC 分别向 PyPI 发布了 litellm v1.82.7 和 v1.82.8——这两个版本在 GitHub 仓库中不存在对应的 tag 或 release。

两个恶意版本的技术解剖

两个版本采用了不同但互补的注入策略，v1.82.8 的技术手段明显更加危险。

v1.82.7 在 litellm/proxy/proxy_server.py 第 128 行嵌入了 12 行混淆代码，使用三层 base64 嵌套编码。该载荷仅在 import litellm.proxy.proxy_server 时触发。v1.82.8 则进一步升级：在 wheel 包中添加了一个名为 litellm_init.pth 的文件（34,628 字节），利用 Python 的 site.py 机制在任何 Python 解释器启动时自动执行，无需任何 import 操作。该 .pth 文件通过 subprocess.Popen 生成子进程来执行恶意载荷。

恶意载荷采用三阶段攻击架构：

第一阶段——凭证收割。代码扫描受害机器上极其广泛的敏感文件和数据，包括 SSH 私钥和配置（~/.ssh/）、所有环境变量和 API 密钥、AWS/GCP/Azure/Kubernetes 云平台凭证、Git 凭证、.env 文件、各种 shell 历史记录、11 种加密货币钱包（Bitcoin、Litecoin、Dogecoin、Zcash、Dash、Ripple、Monero、Ethereum、Cardano、Solana 等）、SSL/TLS 私钥、CI/CD 配置（Terraform、GitLab CI、Travis CI、Jenkins）、数据库凭证（PostgreSQL、MySQL、Redis、MongoDB）、Docker 配置、Slack 和 Discord webhook，以及云元数据端点（IMDS、容器凭证）。

第二阶段——加密外泄。窃取的数据使用硬编码的 4096 位 RSA 公钥加密 AES-256-CBC 会话密钥，然后将所有数据打包为 tpcp.tar.gz，通过 HTTPS POST 发送至攻击者控制的 https://models.litellm[.]cloud/（而非合法的 litellm.ai）。v1.82.7 还使用了 checkmarx[.]zone 作为外泄端点。

第三阶段——横向移动与持久化。如果检测到 Kubernetes 服务账号令牌，代码会读取集群中所有命名空间的全部 Secret，并尝试在 kube-system 命名空间的每个节点上部署名为 node-setup-* 的特权 alpine:latest Pod，挂载宿主文件系统。同时，代码在本地安装持久后门 ~/.config/sysmon/sysmon.py，通过 systemd 用户服务（sysmon.service，伪装描述为"System Telemetry Service"）每 50 分钟轮询 checkmarx[.]zone/raw 获取下一阶段载荷。该后门还内置了一个杀开关：若 URL 返回内容包含 youtube.com 则中止执行。

一次意外的 fork bomb 揭开了攻击

发现者是 FutureSearch 公司的工程师 Callum McMahon。他当时正在测试一个 Cursor IDE MCP 插件，litellm 作为传递依赖被自动拉入。v1.82.8 的 .pth 文件在 Python 启动时通过 subprocess.Popen 生成子进程，而子进程启动时又触发了同一 .pth 文件，形成指数级进程倍增——这是恶意代码作者的一个 bug，意外制造了 fork bomb。McMahon 的机器因 RAM 耗尽而崩溃，他随即展开调查，使用 Claude Code 辅助进行根因分析，并在 FutureSearch 博客上公开了发现。

消息在约 11:00 UTC 传播至 Reddit（r/LocalLLaMA、r/Python）和 Hacker News。约 11:25 UTC，PyPI 对整个 litellm 包实施了隔离。从恶意版本发布到被隔离，暴露窗口约为 3 小时。

TeamPCP 随后采取了积极的反应急响应措施：约 12:44 UTC，数十个 AI 生成的垃圾评论（"Thanks, that helped!"等）在 102 秒内涌入 GitHub issue #24512，试图淹没安全讨论——其中 19/25 个垃圾账号同样被用于此前的 Trivy 垃圾评论攻击。约 13:03 UTC，该 issue 被攻击者利用被入侵的维护者账号关闭为"not planned"。攻击者还在维护者的 fork 仓库中推送了一条 commit，内容为 "teampcp owns BerriAI"。20:15 UTC，恶意版本被正式撤回（yank），PyPI 隔离解除。

影响范围远超 LiteLLM 本身

LiteLLM 每日下载量约 340 万次，每月约 9500–9700 万次，是 AI 基础设施栈中最关键的依赖包之一。它作为统一 LLM API 网关，被部署在大量企业环境中管理对 100+ LLM 供应商的 API 密钥。

主要受影响的下游项目和生态包括：

• DSPy（Stanford NLP）：使用 LiteLLM 作为默认 LLM 后端。Andrej Karpathy 明确指出，执行 pip install dspy（依赖 litellm>=1.64.0）的用户会被传递感染
• CrewAI（v0.86.0+）：已将 LangChain 替换为 LiteLLM 进行所有非原生 LLM 供应商调用
• 大量 MCP 服务器和插件：Cursor IDE 等工具的 MCP 插件广泛依赖 litellm
• 企业 AI 代理网关：作为集中式 LLM 网关部署，天然持有多个模型供应商的 API 凭证
• MLflow 已紧急将 litellm 依赖锁定至 <=1.82.6

在中国 AI 开发者生态中，LiteLLM 同样使用广泛，特别是在需要统一调用百度文心、阿里通义千问、DeepSeek 等多个国内外 LLM API 的场景下。国内 PyPI 镜像源（如阿里云镜像）可能缓存了恶意版本，增加了暴露风险。LINUX DO 论坛是最早发布中文速报的社区平台。

官方回应与安全公告追踪

BerriAI CEO Krrish Dholakia 在 Hacker News 上确认了攻击源头为 CI/CD 中被投毒的 Trivy，并声明："We have deleted all our PyPI publishing tokens. Our accounts had 2FA, so it's a bad token here. We're reviewing our accounts, to see how we can make it more secure (trusted publishing via JWT tokens, move to a different PyPI account, etc.)."

关键跟踪记录包括：GitHub Issue #24512（原始技术分析，被攻击者关闭后由社区重新记录）、#24518（完整时间线和状态更新）、#24521（补充安全报告）。官方安全公告方面，PyPA 发布了 PYSEC-2026-2 公告，明确指出 v1.82.7 和 v1.82.8 受影响，建议所有安装过这两个版本的用户"假设 litellm 环境中可访问的任何凭证都已泄露，应立即轮换"。Snyk 以 SNYK-PYTHON-LITELLM-15762713 跟踪该事件。NVIDIA 开发者论坛也发布了紧急警告。

LiteLLM 的历史漏洞同样值得警惕

供应链攻击之外，LiteLLM 在 2024–2025 年间还积累了 14+ 个 CVE，暴露出代理服务器组件中系统性的安全设计缺陷。

最严重的包括 3 个严重级别漏洞：CVE-2024-2952（SSTI 模板注入，CVSS 9.8）通过 /completions 端点的 Jinja 模板引擎实现任意代码执行；CVE-2024-4264（RCE，CVSS 9.8）通过 litellm.get_secret() 中的 eval() 函数实现远程代码执行；CVE-2024-5751（RCE，CVSS 9.8）通过 add_deployment 函数的 base64 解码环境变量触发任意代码执行。

高危漏洞同样密集：CVE-2024-6587（SSRF）允许攻击者通过 api_base 参数窃取 OpenAI API 密钥；CVE-2024-6825（RCE）通过 post_call_rules 配置解析调用 os.system；CVE-2024-4890 和 CVE-2024-5225 为 SQL 注入；CVE-2025-0628 允许权限提升至 PROXY ADMIN；CVE-2025-0330 导致 Langfuse API 密钥泄露。此外，GitHub Issue #14446 还报告了 LiteLLM Dashboard 中存在恶意 fs npm 包（MAL-2025-21003，CVSS 9.8）。

LiteLLM 已通过 SOC 2 Type I 认证和 ISO 27001 认证，但这些合规标记未能阻止供应链攻击——安全扫描器本身成了攻击入口。

TeamPCP 更大的攻击版图

LiteLLM 事件是 TeamPCP 2026 年 3 月系统性攻击运动的一部分，该组织的攻击横跨 5 个生态系统：GitHub Actions、Docker Hub、npm、Open VSX 和 PyPI。所有攻击共享一致的基础设施特征——相同的 RSA 密钥对、tpcp.tar.gz 命名约定、tpcp-docs-* 前缀的 GitHub 仓库作为 dead-drop C2。

特别值得关注的是 TeamPCP 部署的 CanisterWorm——一种利用 Internet Computer Protocol（ICP）作为 C2 通道的 npm 自传播蠕虫，这是首次观测到 ICP 被用作 C2 基础设施。另一个组件 hackerbot-claw 使用名为 OpenClaw 的 AI Agent 进行自动化攻击目标识别——Aikido Security 的研究人员将其记录为首批在供应链攻击中使用 AI Agent 进行操作性攻击的案例之一。中国国家互联网应急中心（CNCERT）已通过微信发布 OpenClaw 安全风险警告，CNNVD 截至 3 月 9 日已采集 82 个 OpenClaw 相关漏洞。

Wiz 研究团队认为 TeamPCP 已开始与 LAPSUS$ 勒索组织合作。TeamPCP 在 Telegram 上声明："这些公司声称保护你的供应链，却连自己的都保护不了……我们已经在与其他团队合作继续制造混乱。"

受影响用户应立即采取的行动

对于任何可能安装了 litellm v1.82.7 或 v1.82.8 的环境，应按以下优先级执行应急响应：

1. 版本确认：执行 pip show litellm 检查当前安装版本。若为 1.82.7 或 1.82.8，视为完全被入侵
2. IoC 检查：搜索 litellm_init.pth 文件（site-packages 目录下）；检查 ~/.config/sysmon/sysmon.py 和 ~/.config/systemd/user/sysmon.service 是否存在持久化后门；Kubernetes 环境审计 kube-system 中名为 node-setup-* 的异常 Pod
3. 全面凭证轮换：SSH 密钥、所有云平台凭证（AWS/GCP/Azure）、Kubernetes 配置、LLM API 密钥、数据库密码、CI/CD 令牌、加密货币钱包密钥——凡是受影响机器可能接触过的凭证一律轮换
4. 降级与缓存清理：降级至 v1.82.6（pip install litellm==1.82.6）或等待官方安全版本；执行 pip cache purge 或 rm -rf ~/.cache/uv 清除包缓存，防止从缓存重新安装恶意版本
5. 网络取证：检查是否有到 models.litellm[.]cloud 或 checkmarx[.]zone 的出站连接记录

结论：AI 基础设施的阿喀琉斯之踵

这起事件深刻揭示了 AI 基础设施供应链的系统性脆弱。LiteLLM 作为连接企业与 100+ LLM 供应商的核心网关，天然聚合了组织中最有价值的凭证资产——这使其成为攻击者的理想目标。安全扫描器（Trivy）本身成为攻击载体这一事实，构成了对"安全左移"理念的尖锐讽刺。未锁定的 CI/CD 依赖版本、可被 API 令牌绕过的 2FA、以及 .pth 文件这种鲜为人知的 Python 自动执行机制的武器化，共同构成了一条完整的攻击链。TeamPCP 使用 AI Agent（OpenClaw）自动化识别攻击目标，标志着供应链攻击正在进入AI 辅助的新阶段。对于所有依赖开源 AI 工具链的组织，这起事件是一个明确信号：锁定依赖版本、启用 PyPI Trusted Publishing、审计 CI/CD 中的第三方工具链不再是可选项。