文章总结： 2026年3月，开源AIAPI网关LiteLLM在PyPI上遭黑客组织TeamPCP供应链投毒，恶意版本1.82.7和1.82.8内置凭证窃取器，可收割云凭证、K8s配置、LLMAPIKey等高价值资产，并通过AES+RSA加密外传至伪造域名，还能横向移动和持久化驻留。文章提供了完整的本地检测六步法、应急加固流程（隔离、全量凭证轮换、环境重建）以及依赖锁定哈希校验、SBOM管理、沙箱预审、出站管控等七项供应链安全体系化建议，强调AI时代需从边界防守转向依赖链可信验证。 综合评分： 82 文章分类： 供应链安全,应急响应,漏洞分析,AI安全,漏洞预警

AI基础设施地震：LiteLLM遭供应链投毒，应急手册来了

原创

WorkBuddy WorkBuddy

海狼风暴团队

2026年3月26日 16:15 新疆

事件速览

2026年3月24日，安全媒体 CyberKendra 披露：开源 AI API 网关 LiteLLM 在 PyPI 上被植入后门，受影响版本为 1.82.7 和 1.82.8。

LiteLLM 是当前 AI 生态中的关键基础设施——它为 OpenAI、Anthropic、Azure、Bedrock 等 100+ 个大模型提供统一调用接口，广泛用于企业 AI 网关、RAG 系统、LLMOps 平台。一旦中招，攻击者等于拿到了你所有 AI 相关凭证的钥匙。

安全公司 Endor Labs 溯源后发现，此次攻击由黑客组织 TeamPCP 发起。他们此前已入侵了 Aqua Security 的 Trivy 扫描器，继而借助 LiteLLM CI/CD 流水线中集成的 Trivy，悄然获取了 PyPI 发布权限，完成了这次精心策划的供应链攻击。

攻击手法拆解：三阶段组合拳

阶段一：凭证收割机

恶意代码内置大范围凭证窃取器，扫描并外传：

| 窃取目标 | 具体内容 | | — | — | | 云凭证 | AWS ~/.aws/、GCP 服务账号密钥、Azure 凭证 | | 容器与编排 | Kubernetes ~/.kube/config、各命名空间 Secrets | | 代码托管 | SSH 私钥、GitHub/GitLab Token、Git 全局配置 | | CI/CD | Jenkins、GitHub Actions、GitLab CI 流水线 Token | | 数据库 | 数据库连接字符串、密码文件 | | AI 相关 | OpenAI API Key、Anthropic Key、各类 LLM 凭证 | | 其他 | 加密货币钱包、TLS/SSL 私钥、Shell 历史命令 |

外传地址为伪造域名 models.litellm.cloud（官方域名为 litellm.ai），且数据全程经 AES-256-CBC + RSA-4096 双重加密，极难被流量检测工具发现。

阶段二：横向移动

利用窃取到的 Kubernetes 凭证，在集群节点间横向渗透，持续扩大权限范围。

阶段三：持久化后门

在受害环境植入伪装成”系统遥测服务”的持久化后门，确保即使事主发现异常、删包重装，攻击者仍可重新控制。

触发机制：两种版本，一个更狠

版本 1.82.7：恶意代码藏在 litellm/proxy/proxy\_server.py，需 import 该模块才触发——适用于使用 LiteLLM Proxy 的用户。

版本 1.82.8（升级版）：在 Wheel 包中塞入 litellm\_init.pth 文件。Python 解释器启动时会自动扫描 site-packages 目录下所有 .pth 文件并执行其中代码。

⚠️ 这意味着：1.82.8 的恶意代码在你运行任何 Python 命令时就会执行，甚至不需要 import litellm。

🔍 一、本地检测：你还安全吗？

Step 1：确认当前版本

pip show litellm | grep Versionpython -m pip freeze | grep '^litellm=='

若输出为 1.82.7 或 1.82.8，立即进入应急流程。

Step 2：搜索恶意 .pth 文件

find $(python -c "import site; print(site.getsitepackages()[0])") \-name "litellm_init.pth" 2>/dev/nullfind / -name "litellm_init.pth" -type f 2>/dev/null

若发现该文件，环境已被污染，直接跳至加固章节。

Step 3：检查 proxy_server.py 是否被篡改

path "*/litellm/proxy/proxy_server.py"grep -n "base64\|urllib\|socket\|subprocess\|exec\|eval\|__import__" \/path/to/litellm/proxy/proxy_server.py | head -30

Step 4：检查网络外联痕迹

grep -r "litellm.cloud" /var/log/ 2>/dev/nulldscacheutil -cachedump -entries Host 2>/dev/null | grep litellmlsof -i -n -P | grep -i litellmss -tnp | grep python

Step 5：使用 Trivy 进行依赖审计

trivy fs --scanners vuln,secret .trivy image your-image:tagtrivy fs --format cyclonedx --output sbom.json

注意：使用前请确保 Trivy 自身版本安全（建议从官方 GitHub Releases 验证哈希后安装）。

Step 6：排查持久化后门迹象

systemctl list-units --type=service | grep -i "telemetry\|monitor\|agent\|update"crontab -lcat /etc/cron.d/* 2>/dev/nullgrep -n "curl\|wget\|nc\|bash\|python" ~/.bashrc ~/.zshrc 2>/dev/null

🔒 二、应急加固：如果已中招

1. 立即隔离

将受感染的机器或容器从网络隔离，防止凭证继续外传和横向移动。

2. 凭证全量轮换（最高优先级）

假设所有凭证已泄露，立即更换以下内容：

• [ ] AWS Access Key / Secret Key（在 IAM 控制台吊销旧密钥）

• [ ] GCP 服务账号密钥（重新生成 JSON 密钥文件）

• [ ] Azure 服务主体凭证 / Managed Identity

• [ ] Kubernetes Service Account Token 和 kubeconfig

• [ ] SSH 密钥对（撤销公钥，重新生成并分发）

• [ ] GitHub / GitLab Personal Access Token

• [ ] 所有 LLM API Key（OpenAI、Anthropic 等）

• [ ] 数据库密码、连接字符串

• [ ] TLS/SSL 私钥（重新申请证书）

• [ ] CI/CD 平台的所有 Secrets 和 Variables

1. 卸载并重建环境

pip uninstall litellm -y-name "litellm_init.pth" -deletepip install litellm==1.82.6

⚠️ 强烈建议：直接销毁受污染的虚拟环境或容器，从干净的基础镜像重建，并在重建后注入新凭证。不要复用旧环境的任何缓存。

4. 审计近 48 小时 CI/CD 流水线

检查受影响时间窗口内所有流水线的构建日志，重点关注：

• 是否有异常的出站网络请求

• 是否有意料之外的文件下载或执行

• Secrets 是否在日志中被明文打印

🛡️ 三、防御体系建设：供应链安全怎么做

此次事件的本质是信任链断裂——开发者信任了 PyPI 上的包名，却无法感知背后的恶意注入。以下是蓝队应对供应链攻击的体系化建议：

1. 依赖版本锁定 + 哈希验证

pip download litellm==1.82.6 --no-deps -d /tmp/pkgspip hash /tmp/pkgs/litellm-1.82.6*.whl

在 requirements.txt 中锁定哈希：

litellm==1.82.6 \--hash=sha256:YOURHASHHERE

安装时强制校验：

pip install --require-hashes -r requirements.txt

2. 引入 SBOM（软件物料清单）流程

将 SBOM 生成纳入 CI/CD 流水线，每次构建都输出依赖清单，并与上一次版本 diff 对比：

yamlname: Generate SBOMrun: trivy fs --format cyclonedx --output sbom.json .name: Upload SBOM artifactuses: actions/upload-artifact@v4with:name: sbom-${{ github.sha }}path: sbom.json

3. 在沙箱中预审新版本

不要在生产环境直接升级依赖。建立”金丝雀依赖审计”机制：

1. 新版本首先进入隔离沙箱（无网络访问权限、无真实凭证）

2. 运行行为监控（系统调用、网络请求、文件访问）

3. 通过审计后，再推进到 staging → production

4. 最小化 CI/CD 凭证权限

• 使用短期 Token（如 AWS OIDC、GitHub Environments with Protection）替代长期 Key

• 每个 Pipeline 仅赋予完成当前任务所需的最低权限

• 定期审计 Secrets 使用情况，清理不再使用的凭证

1. 网络出站管控

在容器或 CI 环境中，限制出站域名白名单。对于 AI 应用环境：

允许：.openai.com,.anthropic.com, *.litellm.ai

拒绝：*.litellm.cloud（伪造域名）, 其他未知域名

6. 监控异常外联行为

在 SIEM 或 EDR 中配置以下告警规则：

• Python 进程向非白名单域名发起 HTTPS 请求

• Python 进程访问 ~/.aws/、~/.kube/、~/.ssh/ 等敏感目录

• site-packages 目录下出现新增 .pth 文件

1. 建立依赖安全基线

pip install pip-auditpip-audit -r requirements.txt

💡 写在最后：AI 时代的供应链安全

LiteLLM 此次中招，不是个例，而是 AI 时代供应链攻击的一个缩影。

AI 开发环境天然集中了企业最高价值的凭证——云平台密钥、模型 API Key、数据管道 Token。攻击者清楚地知道：一个 AI 基础设施组件的沦陷，价值远超普通开发工具。

对蓝队而言，防御重心需要从”边界防守”迁移到”依赖链可信验证”。不要因为是知名开源项目就无条件信任，每一次 pip install 背后，都是一次信任决策。

快速行动 Checklist

• [ ] 检查 pip show litellm 版本是否为 1.82.7 或 1.82.8

• [ ] 搜索 litellm\_init.pth 文件

• [ ] 检查 proxy\_server.py 是否被篡改

• [ ] 按需轮换全部相关凭证

• [ ] 降级至 1.82.6 或从干净环境重建

• [ ] 审计近 48 小时 CI/CD 日志

• [ ] 锁定依赖版本，启用哈希校验

• [ ] 将 SBOM 生成纳入流水线

参考链接：cyberKendra 原文报道（事件首发披露） 👉 https://cyberkendra.com（可在站内搜索 "LiteLLM"）IT之家报道（中文事件摘要） 👉 https://stock.jrj.com.cn/2026/03/25135556461893.shtmleimoon.com 技术复盘文章（攻击方式与止损建议，信息最全） 👉 https://blog.eimoon.com/p/litellm-pypi-supply-chain-attack-analysis/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：海狼风暴团队 WorkBuddy WorkBuddy《AI基础设施地震：LiteLLM遭供应链投毒，应急手册来了》