LiteLLM 二进宫：你的 LLM 网关开始把你的密钥转发给别人了

LiteLLM 是夹在应用和几十家 LLM 供应商之间的 Python SDK 兼代理，所以它手里往往攥着公司所有供应商的密钥。2026年10月21日 11:39 UTC，恶意的 litellm==1.107.0 出现在 PyPI 上；从 11:46 UTC 起，v1.107.0、latest、main-latest 和 main-stable 这几个官方 Docker 镜像标签也都指向了投毒构建。这是 LiteLLM 今年第二次发布流水线被攻破，上一次是 3 月的 1.82.7 和 1.82.8。JFrog 和 Datadog 表示，目前没有证据把两次事件联系起来。

怎么流出去的

根据 LiteLLM 自己的报告，攻击者手里有三名工程师的 GitHub CLI OAuth 令牌。其中一个属于组织所有者，被用来绕过私有发布工作流的分支保护，并把它指向 Berri-AI/litellm：一个和真仓库 BerriAI/litellm 只差一个连字符的山寨仓库。第二个令牌通过了生产发布的审批关卡，第三个事后删掉了工作流运行记录。真正的 v1.107.0 git 标签是干净的。这些制品是用攻击者的副本构建、再由真实流水线签名的。LiteLLM 怀疑令牌是通过一个暴露在公网的内部部署泄露的，可能利用了一个最近刚修复的漏洞，但初始入口尚未证实。

载荷干了什么

1.107.0 的七个 wheel 包都多了三个文件：cook.pth、cook.py 和 sitecustomize.py，源码包里没有。因为有 .pth 钩子，这个窃取程序会在该环境里每次 Python 启动时运行，哪怕根本没人 import LiteLLM，哪怕你只是在跑 pip。据 Socket 和 JFrog 分析，它会收集：

• 云凭据（AWS、Azure、GCP）、实例元数据令牌，外加一次 STS GetCallerIdentity 校验
• Kubernetes、Docker、Vault、Terraform 和 CI 的密钥；SSH、GPG 和 TLS 私钥；git、npm 和 PyPI 配置
• AI 工具的凭据（Claude、Codex、Gemini、Cursor、Copilot、Hugging Face 等）
• 浏览器数据库、shell 历史，以及 Linux 上所有可读进程的环境变量
• 如果设置了 DATABASE_URL，还会拿走 LiteLLM 代理自己的 LiteLLM_CredentialsTable 和 LiteLLM_ProxyModelTable，你的供应商密钥就存在这两张表里

数据加密后（AES-256，密钥用 RSA-4096 包裹）POST 到 www.litellm[.]dev/healthcheck。sitecustomize.py 还会 fork 出一个脱离终端的守护进程，每小时去 GitHub 上的一个 dead drop 查一次域名，然后从那里下载 Python 代码并直接 exec()，不做任何完整性校验。研究人员查看时这个 dead drop 是空的，之后也已被删除，但窃取部分并不依赖它。

有人在用吗？

有。Wiz 观察到，在数据外传约 4.5 小时后，被盗的 AWS 实例角色凭据从 168.100.8.57 和 165.227.201.8 被拿去验证，并在“少数”环境中出现了 IAM 枚举。Datadog 表示在野没有看到第二阶段载荷。没有任何来源给出 1.107.0 的下载量；唯一被引用的数字是 LiteLLM 总体每周约 2300 万次下载，这并不等于受影响范围。

为什么是 L4

一个按设计就握着所有 LLM 供应商密钥的包，一个只要 Python 启动就偷云和 AI 凭据的载荷，再加上已证实攻击者在使用被盗凭据：这就是正在发生的利用加大规模凭据窃取。没到 L5，是因为只涉及一个版本、在线约两小时、不会自我传播，也没有哪个核心运行时或信任根被攻破。

还没搞清楚的

• 准确的时间窗口。 LiteLLM 说 PyPI 在 13:23 下架、Docker Hub 在 14:20 UTC 前清理完毕；Wiz 和 Datadog 说是 13:20 和约 13:53；GitHub issue 里报告 13:23 时 Docker 标签仍是坏的，到 17:13 才撤下。如果你那天下午任何时候拉过浮动标签，去核对一下 digest。
• 工程师令牌的初始入口只是怀疑，尚未证实。
• 目前还没有 GHSA 或 CVE。Wiz 的编号是 wiz-adv-2026-188，JFrog 的是 XRAY-955589。
• LiteLLM 提到一个定于 10月27日披露的企业版修复，目前处于保密期，不清楚和这次事件有没有关系。