pip 装一次就端走整面渠道墙：LiteLLM 1.107.0 的两小时，把聚合网关的密钥账翻了出来

10 月 21 日 11:39（UTC），PyPI 上架了一个版本号完全正常的包：litellm 1.107.0。它走的是官方发布通道，构建来源凭证齐全，七个平台 wheel 全部就位，Docker 镜像同步推送。两小时后它被隔离下架——但这两小时里，任何一次 pip 安装或容器拉取，都在 site-packages 根目录留下了三个文件。

时间线上，被压缩的只有反应时间

按 Datadog 安全实验室与 LiteLLM 官方复盘：11:39 恶意版本进入 PyPI，13:20 PyPI 隔离该版本，13:53 受影响 Docker 镜像被移除；另一份分析记录 Docker Hub 上的相关标签直到 14:20 UTC 才真正停服，比 PyPI 多出近一小时。防守方并不慢——有依赖防火墙厂商记录，恶意 wheel 上传后 3 分 14 秒就被标记，12:00 前七个 wheel 全部确认恶意。问题在于这个包周下载量约 2300 万次，两小时足够覆盖大量 CI 与推理代理容器。

为什么它对聚合分发这一层格外致命

注入的是三个文件：12 字节的 cook.pth、22,252 字节的 cook.py、25,509 字节的 sitecustomize.py。cook.pth 只有一行 import cook，而 CPython 在解释器启动时就会执行 .pth 里的 import 语句——不需要项目里调用 litellm，pip 本身、pytest、Jupyter 内核、IDE 语言服务都会触发。

真正与聚合层相关的是采集清单。除浏览器口令与 cookie、AWS/GCP/Azure 凭据、SSH/GPG 私钥、Vault 与 CI 令牌之外，有两个模块专门冲着网关来：db_litellm 读取 DATABASE_URL，把 LiteLLM_CredentialsTable 与 LiteLLM_ProxyModelTable 两张表整表导出。这两张表里放着的，正是代理替所有下游调用方保管的上游厂商密钥。一次供应链事故，丢的不是一把 key，而是整面渠道墙的 key 一次被端走。数据用 AES-256-CBC 加密、密钥再用 RSA-4096 包一层，回传目标是 litellm.dev/healthcheck；该域名 10 月 13 日注册，比投放早 8 天，而项目自己的域名是 litellm.ai。另有一个后门每小时去固定 GitHub 仓库取新域名，再拉取执行代码。

我的判断：密钥的仓库化必须分段

这不是孤例。LiteLLM 今年已是第二次被投毒，上一次涉及 1.82.7 与 1.82.8（Datadog 关联到 TeamPCP，两起暂未确认同源）。对做多模型接入的团队，我会按这个顺序处置：

一、先按已泄露处理。检查 /tmp/.pc_once_* 与 /tmp/remote_code_loader.lock，命中即说明窃取已发生或后门仍在运行；回退 1.106.2，容器改按 digest 钉版本——latest、main-latest、main-stable 三个标签都在受影响名单里，标签本身不构成清白证明。

二、按一个渠道一个子账号重排密钥。假设一个网关接 8 家供应商、生产与测试各一把 key，按每家 20 分钟轮换加回归验证计，一次全量轮换约 5.3 人时；把凭据拆成按渠道、按调用方分级的子 key，轮换面就能从全量缩到命中渠道。这 5.3 人时是给定假设下的估算，不是行业基准。

三、给每个渠道设日预算与速率上限。密钥失窃后最贵的不是补发，是被拿去刷量；预算上限能把损失封在一天的量级，而不是等月底对账才发现。

四、把推理网关单独列进第三方风险清单，和云厂商同级评估。它天然持有全部渠道凭据，风险集中度高于任何单家模型厂商；聚合平台在选型时，网关的可审计性与凭据隔离能力，应该和价格、延迟并排列在同一张表里。

来源：Datadog Security Labs、The Register、Wiz、SafeDep、Sesame Disk