概述

LiteLLM 是一款应用广泛的开源 Python 库及 AI 网关（代理服务器），支持将 100 多种大语言模型 API 统一转换为 OpenAI 格式，常被集成到 AI 代理、MCP 服务器、LLM 编排工具及企业级 AI 流程中。该 PyPI 包的月下载量超过 9500 万次，在云环境中的渗透率约为 36%。2026 年 3 月 24 日，LiteLLM 遭遇了一次典型的供应链攻击，攻击者 TeamPCP 通过 PyPI 上传了恶意版本 litellm==1.82.7 和 litellm==1.82.8。

此次攻击是 TeamPCP 黑客组织系列攻击中的最新一环（此前已入侵过 Aqua Security 的 Trivy 扫描器和 Checkmarx 的 KICS GitHub Action），波及范围广，隐蔽性较强，并利用 Python 生态中的 .pth 机制实现了“无需 import 即可执行”。好消息是本次恶意版本暴露时间较短，大约 3 小时后 PyPI 便已迅速将其隔离，官方也及时作出响应。以下是对本次供应链攻击的详细技术细节与应对建议。

事件时间线

  • 2026 年 3 月 19 日前后：TeamPCP 通过针对 Trivy 的供应链攻击窃取了部分凭证（包括 LiteLLM 的 CI/CD 流水线中使用的凭证）。

  • 2026 年 3 月 24 日 08:30 UTC 左右：攻击者利用窃取到的 PyPI 维护者凭证，绕过了官方 CI/CD 流程，直接向 PyPI 上传了恶意版本 1.82.7 和 1.82.8。

  • 约 11:25 UTC：PyPI 检测到异常并将这两个版本隔离。

  • 3 月 24 日下午：LiteLLM 官方发布安全公告，移除恶意包、轮换相关凭证，并邀请 Mandiant 协助取证。

  • 3 月 25 日至今：多家安全机构（Wiz、Snyk、Endor Labs、FutureSearch 等）发布了详细分析，社区在 Reddit、HN、X 等平台上也展开了广泛讨论。

攻击根因：链式供应链污染

此次攻击并非直接攻破 LiteLLM 的代码仓库，而是利用了之前攻击中窃取到的凭证：

  • LiteLLM 的 CI/CD 安全扫描流程依赖 Trivy（当时已被 TeamPCP 攻陷）

  • Trivy 事件导致了 LiteLLM 维护者的 PyPI API token 泄露。

  • 攻击者直接用该 token 向 PyPI 上传了恶意的 wheel 和 sdist 包，绕过了 GitHub 上的官方发布流程（因此源码仓库本身并未被污染）。

这也反映出供应链攻击的“链式放大”效应：攻破一个安全工具（Trivy），就可能影响到大量依赖它的下游项目。

恶意载荷分析

两个恶意版本的 payload 略有不同，但核心目标都是窃取凭证、持久化、横向移动：

  • 1.82.7：在 litellm/proxy/proxy_server.py 中植入了经过双重 base64 编码的 payload，仅在运行 litellm --proxy 或导入 litellm.proxy.proxy_server 时触发。

  • 1.82.8（风险更高）：额外增加了 litellm_init.pth 文件（约 34KB），利用 Python 的 .pth 机制（安装后会被 site.py 自动执行），只要 Python 解释器启动就会运行，无需显式 import litellm。

Payload 执行流程

凭证收集

  • 扫描并窃取 SSH 私钥、.env 文件、各大云厂商（AWS/GCP/Azure）凭证、Kubernetes 配置和 token、数据库密码、Git 配置、Shell 历史、加密钱包、TLS 私钥、CI/CD secret、环境变量等。

  • 额外执行命令导出环境变量（dump env），并尝试访问云平台的元数据服务（IMDS）。

加密与回传

  • 使用硬编码的 4096 位 RSA 公钥配合 AES-256-CBC 加密（每次随机生成 session key）。

  • 将数据打包为 tpcp.tar.gz，通过 POST 请求发送至攻击者控制的域名：

  • 1.82.7 → checkmarx[.]zone

  • 1.82.8 → models.litellm.cloud（该域名非 LiteLLM 官方所有，官方已明确否认）

持久化与横向移动

  • 本地持久化：在 ~/.config/sysmon/sysmon.py 中安装后门，伪装成“System Telemetry Service”，并创建 systemd user service。

  • Kubernetes 环境（高危）：读取所有命名空间中的 secret，利用 service account token 在 kube-system 命名空间下创建特权 pod（镜像为 alpine:latest，pod 名称模式为 node-setup-*），挂载宿主文件系统并植入后门。

  • 攻击者声称已从约 50 万台设备中窃取数据（该数据包含重复统计，尚未独立验证）。

意外暴露的原因

.pth 文件的实现存在 bug —— 子进程中的 subprocess.Popen 再次触发了 .pth 执行，形成指数级 fork bomb，导致部分机器内存被耗尽而崩溃，反而使恶意行为暴露（由 FutureSearch 工程师在 Cursor MCP 插件中首次发现）。

IOC（失陷指标）

文件

litellm_init.pth（位于 site-packages 目录）

域名

models.litellm.cloud

checkmarx.zone

持久化路径

~/.config/sysmon/sysmon.py

~/.config/systemd/user/sysmon.service

/tmp/pglog

/tmp/.pg_state

Kubernetes 相关

kube-system 命名空间下出现 node-setup-* 的 pod

影响范围与风险评估

受影响条件

在 2026 年 3 月 24 日 10:39–16:00 UTC 期间通过 pip install litellm 安装（或通过依赖间接安装）了 1.82.7 或 1.82.8 版本。

高危场景

CI/CD 流水线、AI 代理框架、本地开发环境、Kubernetes 集群，这些场景可能导致全集群 secret 泄露和持久化植入。

未受影响的情况

  • 官方 Docker 镜像（ghcr.io/berriai/litellm，已固定依赖版本）
  • LiteLLM Cloud 服务
  • 从 GitHub 源码安装
  • 使用 v1.82.6 及更早版本（且未在风险窗口期内升级）

需要说明的是本次供应链攻击事件的潜在影响较大，由于 LiteLLM 广泛嵌入 AI 工具链中，一旦 CI/CD 环境被污染，可能引发下游数百个项目连锁泄露云凭证。

应对建议

LiteLLM 团队已采取的措施

  • 从 PyPI 下架恶意版本
  • 轮换所有维护者凭证，暂停新版本发布
  • 邀请 Mandiant 进行取证分析
  • PyPI 已发布官方通告（PYSEC-2026-2）

用户/企业紧急缓解建议（按优先级）

1. 检查版本：通过 pip show litellm 确认当前版本，或在虚拟环境、CI 日志、Docker build 日志中检索。

2. 卸载并清理缓存：

  • pip uninstall litellm
  • pip cache purge（若使用 uv，可执行 rm -rf ~/.cache/uv）
  • 查找并删除 litellm_init.pth 文件

3. 全面轮换凭证：将所有 SSH 私钥、云服务 access key、K8s token、API key、数据库密码等视为已泄露，尽快更换。

4. 检查持久化痕迹：搜索上述 IoC 中的文件及 Kubernetes pod。

5. 锁定安全版本：在 requirements.txt 或 pyproject.toml 中固定 litellm<=1.82.6，或等待官方确认的下一个干净版本。< p="">

6. 加强监控：若网络流量中出现 models.litellm.cloud 或 checkmarx.zone，应立即排查。

安全启示与长期建议

1.供应链攻击的现实威胁

仅依赖单个 PyPI 发布账号且未对 CI/CD 凭证做有效隔离，风险较高。TeamPCP 的“Trivy → LiteLLM”链式攻击表明，安全工具本身也可能成为攻击入口。

2.Python 生态的薄弱点

.pth 文件的自动执行机制容易被滥用；pip 默认不进行包签名校验；间接依赖往往被忽略。

3.推荐的最佳实践：

  • 始终固定依赖版本（配合 Dependabot 与自动化 SBOM 管理）
  • 使用可信构建方式（如 Trusted Publishing、GitHub OIDC）
  • 部署时优先使用官方 Docker 镜像或源码安装
  • 引入软件成分分析（SCA）工具与运行时检测
  • Kubernetes 环境下建议通过 Pod Security Policy 或 Kyverno 限制特权容器的创建

总结

此次事件再次提醒我们，AI 基础设施的安全不容忽视：流行的项目并不等同于安全，供应链风险正从传统软件领域加速向 LLM 生态渗透。建议使用 LiteLLM 的团队尽快自查，并将依赖管理提升到企业级安全策略的高度。

声明：本文来自奇安信威胁情报中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。