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 标签是干净的。这些制品是用攻击者的副本构建、再由真实流水线签名的。10月24日更正： LiteLLM 在 10月23日的正式报告中取代了此前关于内部部署日志泄露令牌的推测。5 月暴露后未吊销的 Agent Platform 主密钥，让攻击者在 10月10日通过该服务 API 取得所有者令牌，随后恶意 CI 工作流又提取了两个维护者令牌。

载荷干了什么

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。
• 厂商现已确认初始入口： 暴露的主密钥 → Agent Platform API → GitHub 所有者令牌 → CI 密钥外传，修正了此前未经证实的推测。
• 跟踪条目更正： GHSA-92x9-889m-jgmw 现已包含 1.107.0。较早的发布日期和其中的 3 月版本不能证明两次攻击有关。Wiz 和 JFrog 也分别用 wiz-adv-2026-188 和 XRAY-955589 跟踪本次事件。
• LiteLLM 提到一个定于 10月27日披露的企业版修复，目前处于保密期，不清楚和这次事件有没有关系。

11月1日更新（UTC）： 厂商10月30日通知公布替代 cosign 公钥的指纹，并表示旧私钥可能已经泄露。轮换发生于10月23日，首批使用替代密钥签署的版本于10月24日发布。应同时验证固定提交中的公钥和镜像摘要。恶意镜像由真实发布流水线使用旧密钥签署，因此仅有有效签名不能排除此事件的影响。上述暴露主机重建及凭据轮换措施仍然适用。