[Security]: litellm PyPI package (v1.82.7 + v1.82.8) compromised — full timeline and status

问题场景

用户在通过 PyPI 安装或升级 litellm 时，可能拉到了被攻击者直接上传的恶意版本 v1.82.7 / v1.82.8。这两个版本从未经过官方 GitHub CI/CD 发布——GitHub 上的 release 只到 v1.82.6.dev1。恶意代码会收集 SSH 密钥、环境变量（API key、各类 secret）、AWS/GCP/Azure/K8s 凭证、加密钱包、数据库密码、SSL 私钥、shell history 和 CI/CD 配置，用 AES-256-CBC + RSA-4096 加密后 curl POST 外传到攻击者控制的 https://models.litellm.cloud/（注意不是官方域名 litellm.ai，前者在 2026-03-23 通过 Spaceship, Inc. 注册，就在恶意包出现前几小时）。

触发方式分两档：v1.82.7 把 payload 塞进 litellm/proxy/proxy_server.py，需要 import litellm.proxy 才触发；v1.82.8 额外加入了 34,628 字节的 litellm_init.pth，任意 Python 启动即触发，无需任何 import。这是本次事件最危险的一点——即使你的项目根本没用到 litellm，只要那个环境里装着 1.82.8，启动 Python 就会中招。

报错原文

[Security]: litellm PyPI package (v1.82.7 + v1.82.8) compromised — full timeline and status

PyPI 侧的直接表现是包被拉入隔离（quarantine），安装时返回：

No matching distribution found.

原因分析

最可能的原因是供应链攻击，路径为 Trivy → LiteLLM PyPI。据 Issue 评论中的时间线梳理：

• 2026-03-01：Aqua Security（Trivy 维护方）遭初始入侵。
• 凭证轮换不完整，攻击者（TeamPCP）仍持有可用 token。
• TeamPCP 污染了 Trivy v0.69.4–v0.69.6，force-push 了全部 76+ 个 trivy-action tag，并直接向 Docker Hub 推送恶意镜像。
• LiteLLM 的 ci_cd/security_scans.sh 通过 apt 从 aquasecurity 源安装 Trivy 且未锁定版本，会拉到当时的最新版。如果 CI 运行落在 Trivy 被污染的窗口内，就会装上被污染的 Trivy 二进制。
• 被污染的 Trivy 内含凭证窃取代码，会 dump 环境变量和 secrets 并通过 Cloudflare Tunnel 外传——在 GitHub Actions 里这意味着 GITHUB_TOKEN 和仓库 secrets（如 PYPI_PUBLISH_PASSWORD）都可能泄露。
• 2026-03-23：攻击者注册 litellm.cloud 作为外传目标。
• 2026-03-24 约 08:30 UTC：攻击者用窃取到的维护者 krrishdholakia 账号，绕过官方 CI/CD 直接向 PyPI 发布 litellm==1.82.7 和 1.82.8。

因此，PyPI 上的恶意包是”绕过官方发布链路直接上传”的产物，GitHub 仓库源码本身经审计未见注入：所有 tag（v1.82.3-stable 到 v1.82.6.rc.2）中没有 .pth 文件、没有 litellm.cloud 引用、没有 exec(base64.b64decode(...)) 模式，simple_pypi_publish.yml 工作流最后一次修改是 2025 年 7 月，未被篡改。

Issue 评论还提到攻击者可能同时拿到了维护者创建的 PAT（见 krrishdholakia/blockchain 仓库中的可疑 commit），并指出这不仅是 PyPI 的问题，因此清理后需要全量轮换涉及的所有 secret 及关联服务（含 PyPI 等）。

后续状态：被污染的包已被删除，所有维护者账号已轮换（新账号 @krrish-berri-2、@ishaan-berri），在完成全链路扫描确认安全前不再发布新版本，并已聘请 Google Mandiant 团队介入。PyPI 也对该项目做了隔离，阻挡后续下载。

环境排查

• 确认当前环境安装的 litellm 版本号，重点排查 1.82.7 / 1.82.8（其他版本也应审计）。
• 检查 site-packages/ 目录下是否存在 litellm_init.pth（v1.82.8 的特征文件），它是任意 Python 启动即触发的关键。建议用虚拟环境路径定位，例如 python -c "import site; print(site.getsitepackages())" 后到该目录下查找。注意不要贴出该文件内容——如果存在，机器已被污染。
• 排查 CI/CD 流水线：是否在 2026-03 期间运行过 ci_cd/security_scans.sh，以及该脚本是否以 apt 方式安装了未锁定版本的 Trivy。
• 检查在该机器上曾以环境变量或配置文件形式出现过的所有凭证：SSH key、云厂商（AWS/GCP/Azure）凭证、K8s 配置、数据库密码、SSL 私钥、API key、CI/CD secrets、PAT。
• 核对官方 GitHub release 列表，确认你用的版本是否有对应 tag——1.82.7 和 1.82.8 在 GitHub 上不存在 tag，这本身就是判据。

解决步骤

1. 先隔离，再处置。如果确认或高度怀疑装了 1.82.7/1.82.8，把该机器/该容器视为已失陷，不要在上面继续做任何凭证轮换操作。
2. 在干净环境中，到受影响机器的 site-packages/ 下确认 litellm_init.pth 是否存在，作为受影响判据之一。
3. 卸载可疑版本，并确认包来源：只从官方 GitHub release 对应的版本安装，避免直接信任 PyPI 版本号。Issue 建议将依赖 pin 到精确版本并与 GitHub release 交叉校验。
4. 在一台未被污染的干净机器上，轮换所有曾出现在受影响环境中的凭证，包括但不限于：PyPI token、GitHub PAT、云厂商 access key、SSH key、数据库密码、各类 API key。Issue 评论特别指出，在被感染的机器上执行轮换基本无效，因为轮换过程本身也会被窃取。
5. 对已泄露凭证覆盖的所有服务，监控是否存在未授权访问。
6. 检查 CI/CD：为流水线引入版本锁定（例如避免 apt 直接装 latest 的 Trivy），并按需收窄 GITHUB_TOKEN 权限、对仓库 secrets 做轮换与分片隔离。Issue 评论提及其长期建议是”seal and shard secrets”，即对长生命周期的 token 做封存与分片管理，并在流程中引入 2FA 要求（参照 eslint 团队在 eslint-scope 事件后的做法）。
7. 清理完成后，重新安装经校验的干净版本，并保留后续审计记录。

验证方法

确认问题已解决可以看以下几点：

• site-packages/ 下已不存在 litellm_init.pth，且当前 litellm 版本有对应的官方 GitHub release tag。
• PyPI 侧：此前安装会返回 No matching distribution found.，Issue 中确认被污染的包已被删除、当前版本不含恶意代码。
• 所有在原受影响环境中暴露过的凭证已完成轮换，且相关服务的访问日志中没有来自陌生 IP / 陌生地区的异常调用。
• CI/CD 层面：能证明流水线安装的 Trivy（或其他安全扫描工具）版本是经过锁定和校验的，不再随 latest 漂移。

参考来源

BerriAI/litellm #24518

Issue 内引用的其他链接：原始详细分析 #24512；Hacker News 讨论 item?id=47501729；官方 Security Townhall 与 CI/CD v2 说明见 docs.litellm.ai/blog/ 下的对应博文。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。