LiteLLM 被植入恶意代码：2026 年供应链攻击完整分析与紧急应对指南

Key Takeaways

• 受影响版本：LiteLLM PyPI 上的 1.82.7 和 1.82.8 版本被植入恶意代码，已被官方下架。最后安全版本为 1.82.6。
• 攻击机制：1.82.7 在 proxy_server.py 中隐藏负载；1.82.8 额外利用 Python .pth 文件（litellm_init.pth），在任何 Python 进程启动时自动执行，无需 import litellm。
• 窃取内容：SSH 私钥、AWS/GCP/Azure 凭证、Kubernetes 配置与 Secret、.env 文件、加密货币钱包、数据库密码、Git 凭证、Shell 历史等。
• 三阶段攻击：凭证收集 → Kubernetes 横向渗透（创建特权 Pod）→ 持久化后门（伪装成 systemd 服务 sysmon.service）。
• 根因：攻击者通过此前入侵的 Trivy 安全扫描器，获取了 LiteLLM 维护者的 PyPI 发布权限，绕过正常 CI/CD 流程直接上传恶意包。
• 暴露时间：恶意版本上线约 1-2 小时，因恶意代码存在 fork bomb 缺陷导致开发者机器崩溃才被发现。
• 影响范围：LiteLLM 月下载量超过 9500 万次，许多 AI 代理、MCP 服务器和 LLM 编排项目间接依赖该库。

事件时间线与攻击细节

2026 年 3 月 24 日，知名 AI API 统一调用库 LiteLLM 在 PyPI 上出现异常版本。攻击者 TeamPCP（此前已攻击 Trivy、KICS 等安全工具）利用维护者账号或 PyPI token，发布了两个恶意版本。

1.82.7 版本：

• 恶意代码隐藏在 litellm/proxy/proxy_server.py 中。
• 仅在导入该模块或运行 litellm --proxy 时触发。
• 负载为双重 base64 编码的 Python 脚本。

1.82.8 版本（破坏力更强）：

• 额外植入 litellm_init.pth 文件。
• Python 的 site 模块会在解释器启动时自动执行 .pth 中的代码，实现零交互触发。
• 这使得即使从未显式使用 LiteLLM 的项目，只要安装了该包的依赖环境，就会被感染。

恶意代码采用混合加密（AES-256-CBC + RSA-4096），将收集到的数据发送至伪造域名 models.litellm.cloud。

恶意负载的技术剖析

分析显示，负载分为三个阶段：

1. 凭证收集阶段：

   • 递归扫描常见路径：~/.ssh/、~/.aws/、~/.kube/、~/.azure/、~/.env 文件、Kubernetes config、Git credentials 等。
   • 提取环境变量、进程内存中的秘密、云元数据端点（IMDS）。
   • 支持多种加密货币钱包文件。

2. 横向移动阶段（Kubernetes 环境）：

   • 利用 ServiceAccount Token 读取全集群 Secret。
   • 在每个节点 kube-system 命名空间创建特权 alpine:latest Pod，挂载主机文件系统。

3. 持久化阶段：

   • 部署伪装成“系统遥测服务”的后门（sysmon.py + systemd 用户服务）。
   • 定期从 checkmarx.zone 等域名拉取额外 payload。

发现原因：恶意代码中的 subprocess.Popen 调用在 .pth 机制下形成指数级 fork bomb，导致内存耗尽崩溃。这暴露了攻击者代码质量的缺陷，否则危害可能持续数天。

为什么 LiteLLM 成为高价值目标？

LiteLLM 作为支持 100+ LLM 提供商的统一代理，广泛用于生产环境中的 AI 代理系统、MCP 服务器和多模型路由。开发者常用一行代码替换底层调用，这也意味着它常与敏感 API 密钥共存。

供应链攻击链条清晰：Trivy 遭入侵 → LiteLLM CI/CD 扫描依赖 Trivy → 发布权限泄露 → PyPI 直接上传恶意包。这凸显了“信任但验证”在现代开源生态中的重要性。

立即行动：检查与清理步骤

步骤 1：检查已安装版本

pip show litellm
pip list | grep litellm

若版本为 1.82.7 或 1.82.8，立即执行：

pip uninstall litellm -y
pip install litellm==1.82.6 --force-reinstall

步骤 2：清除 Python 缓存与 site-packages

• 删除 site-packages/litellm* 目录及 .pth 文件。
• 清空 pip 缓存：pip cache purge

步骤 3：轮换所有凭证

• 必须 立即轮换 SSH 密钥、所有云平台 Access Key（AWS IAM、GCP Service Account、Azure AD）、Kubernetes 令牌、数据库密码、CI/CD 密钥。
• 检查云审计日志（CloudTrail、Audit Logs、Activity Log），搜索异常访问。

步骤 4：Kubernetes 环境额外检查

• 扫描 kube-system 命名空间中的异常 Pod。
• 审查节点上的 ~/.config/sysmon/ 目录和 systemd 服务。
• 重建受影响节点（推荐）。

步骤 5：依赖项目扫描

• 检查所有使用 requirements.txt、pyproject.toml 或 Docker 镜像的项目，锁定 LiteLLM 版本为 ==1.82.6。
• 使用 pip-audit 或 safety 等工具扫描环境。

高级缓解措施与最佳实践

• 锁定版本：在生产环境中始终使用 litellm==1.82.6 或更高安全版本，并启用依赖锁定（Poetry、Pipenv）。
• SBOM 与供应链扫描：集成 Dependabot、Snyk、JFrog Xray 或 Endor Labs，监控 PyPI 包变更。
• 最小权限原则：避免在同一环境中混用开发与生产凭证；使用 Secrets Manager（如 AWS Secrets Manager、HashiCorp Vault）。
• Air-gapped 或离线安装：对高安全环境，考虑从 GitHub 源码构建并验证哈希。
• 监控异常：部署 EDR 工具，关注 .pth 文件创建、异常 fork 行为及对 models.litellm.cloud 的网络请求。
• 社区建议：Andrej Karpathy 等专家指出，供应链攻击正成为常态，开发者应减少不必要依赖，或通过 LLM 直接实现简单功能以降低风险。

边缘情况注意：

• 通过 CLI 安装脚本（如某些 AI 工具的 install.sh）间接安装的用户同样受影响。
• Docker 镜像若基于受污染的 base image，需重建。
• 虚拟环境（venv）虽隔离，但若在全局 Python 中安装，仍会影响系统进程。

结论

LiteLLM 供应链攻击再次证明，开源生态的便利性与安全风险并存。攻击者通过污染安全工具本身，实现了对下游项目的精准打击。

立即行动：检查所有 Python 环境中的 LiteLLM 版本，降级至 1.82.6，并全面轮换受影响凭证。同时，建议团队建立严格的依赖审核流程，避免类似事件重演。

关注 LiteLLM 官方 GitHub 和 PyPI 公告，等待官方发布更安全的后续版本。开源安全需要全社区共同维护——从锁定版本开始。

保持警惕，定期审计依赖链，是每位 AI 开发者在 2026 年及以后的必备技能。