LiteLLM 1.107.0 供应链污染怎么排查：清 cook.pth、钉 1.106.2、轮换 Key
如果你在2026-10-21前后遇到过下面任一现象，先别急着在原环境里再跑一遍pip install或python -c「探测」——这很可能不是普通依赖冲突，而是LiteLLM 1.107.0 供应链污染留下的痕迹：
- 供应商后台突然出现未解释的用量尖峰，或 Key 额度异常消耗；
- 某个
site-packages根目录多出了陌生的cook.pth、cook.py，或异常的sitecustomize.py； - CI / 本机 Python 一启动就有说不清的钩子行为，而你并没有改过启动脚本；
- Compose / K8s 写着
litellm:latest（或main-latest/main-stable），说不清污染窗口里有没有拉过。
本文按 CSDN 教程检索习惯组织：问题现象 → 原因范围 → 分步操作（可复制命令）→ 验证清单 → 边界。只写公开案情与可执行闸门，不贴 PoC、不写可复现攻击细节、不展开恶意域名。
一、问题现象：先对上号，再选剧本
1.1 常见「像报错、其实是污染」的信号
| 你看到的现象 | 优先怀疑 | 不要先做的事 |
|---|---|---|
site-packages根目录有cook.pth/cook.py | 污染 wheel 植入启动钩子 | 用脏环境的python -c去读这些文件 |
多出异常sitecustomize.py | 启动即加载的植入物 | 在原 venv 里反复pip check/ 重装「试试」 |
| 用量曲线在 10-21 窗口后尖峰 | Key / 凭据可能已摸到 | 只观察一周再轮换 |
| 运行中镜像来自曾污染的浮动标签 | Docker/GHCR 产物曾被改指 | 继续盲信latest |
和前几天「低权限改网关就能动 Key」那条线不要混：那天是权限校验缺口，修法偏升修 RBAC 的版本；今天是发布产物被投毒，修法是停跑 → 清植入物 → 重建钉版本 → 轮换 → 查用量。搜错剧本会浪费整晚。
1.2 你需要先回答的三个是/否
- 10-21 窗口内，本机或 CI 是否执行过未钉版本的
pip install -U litellm/pip install litellm？ - Compose / K8s 是否写着
litellm:latest一类浮动标签，且可能在污染区间拉过？ - 同一台机是否跑着挂有高额度供应商 Key 的 proxy / 自动化任务？
三个里有一个「是」或「不确定」，就按下文完整走一遍；三个都是否，也建议至少过一遍验证清单，别靠感觉。
二、原因范围：毒在哪、谁在半径里
公开案情（LiteLLM 官方事故页，交叉 Endor Labs / Datadog / JFrog / OSV MAL-2026-2144 / Wiz）可压成工程事实：
2.1 时间窗与产物
- PyPI：
litellm==1.107.0约在11:39–13:23 UTC（2026-10-21）在线，约两小时后撤回。 - Docker Hub / GHCR：
v1.107.0、latest、main-latest、main-stable等在约11:46–14:20 UTC曾指向污染产物，随后移除或改指干净源。 - 企业私有 registry：公开口径为未受影响。
- GitHub 官方
v1.107.0源码 tag：本身干净；毒在构建 / 上传链，不在「源码树被人直接改坏」这一层。
2.2 为什么「没 import litellm」也可能中招
恶意 wheel 会在site-packages根目录留下：
cook.pthcook.pysitecustomize.py
刺痛点：任意 Python 进程启动都可能触发，不必import litellm。公开侧描述会摸云 / SSH / 浏览器 / CI 凭据、AI 工具配置，以及 LiteLLM proxy 库里的供应商 Key；另有远程代码加载能力。因此「我项目里没用到 litellm」不能单独当免罪金牌——要看那台机的site-packages里有没有装过污染包。
2.3 谁更可能在半径 / 谁相对安全
更可能在半径
- 窗口期内盲升或未钉版本安装；
- 浮动标签镜像在污染区间拉取并跑过；
- 同机有高额度 Key / proxy。
相对安全（仍建议过验证表）
- 一直钉在
litellm==1.106.2及更早明确安全版； - 只拉企业私有 registry，且能证明拉取源；
- 能证明窗口期内未装未跑污染产物。
「在线只有约两小时」≠「两小时后风险自动归零」——凭证一旦外泄，刷量可以发生在你下班之后。
三、分步操作：停跑 → 清文件 → 重建钉版本 → 轮换 → 查用量
官方处置顺序有点反直觉：不要先在怀疑污染的环境里跑pip install。任意 Python 启动（包括 pip 自己）都可能再次拉起植入物。下面命令按 Linux / macOS 常见路径写；Windows 把路径换成你的site-packages即可，原则相同。
步骤 ① 先停跑：服务、定时任务、交互式解释器
目标：清文件之前，尽量不再触发 site-packages 根目录的启动钩子。
# 示例：按你实际进程名调整# systemdsudosystemctl stop litellm-proxy# 若有同名服务# 或查 Python / litellm 相关进程后结束psaux|grep-E'litellm|uvicorn|gunicorn'|grep-vgrep# 停掉相关 cron / CI runner 上的并发任务后再继续有公开通告提到的、持有异常锁文件的后台进程（与远程加载相关）时：先杀进程，再删文件。
步骤 ② 定位 site-packages，用 shell 删植入物（不要先 python）
先找出可能的site-packages（venv、系统、用户路径都要看）：
# 列出常见 site-packages（在「尚未确认干净」时，尽量用 shell，少启 python）ls-d\.venv/lib/python*/site-packages\venv/lib/python*/site-packages\"$HOME"/.local/lib/python*/site-packages\/usr/lib/python*/site-packages\/usr/local/lib/python*/site-packages\2>/dev/null在每个受影响目录删除植入物及缓存：
SITE=./.venv/lib/python3.11/site-packages# ← 改成你的实际路径# 删除植入物rm-f"$SITE/cook.pth""$SITE/cook.py""$SITE/sitecustomize.py"# 删除对应字节码缓存rm-f"$SITE"/__pycache__/cook*.pyc\"$SITE"/__pycache__/sitecustomize*.pyc# 全盘粗查（只读 find，仍避免 python）find/-name'cook.pth'-o-name'cook.py'2>/dev/null|head-50find/-name'sitecustomize.py'2>/dev/null|head-50用 shell / 文件管理器直接删，不要先python -c "import ..."去探测。容器内路径同理：进到可写层或重建前，把上述文件清掉。
步骤 ③ 重建环境，钉死litellm==1.106.2
优先新建干净 venv（或新机器），不要在脏环境里「覆盖安装」指望一次到位：
# 在确认已清植入物、或全新机器上执行python-mvenv .venv-cleansource.venv-clean/bin/activate pipinstall--upgradepip pipinstall"litellm==1.106.2"pip show litellm# 期望：Version: 1.106.2依赖文件示例（二选一，原则是永远带版本号）：
# requirements.txt litellm==1.106.2# pyproject.toml 片段示例 # dependencies = [ # "litellm==1.106.2", # ]Docker / Compose 侧：
# 不要# image: ghcr.io/berriai/litellm:latest# 要：显式版本，或你已核对过的 digestimage:ghcr.io/berriai/litellm:v1.106.2# 或# image: ghcr.io/berriai/litellm@sha256:<你核对过的干净 digest>- 不要再盲信曾被污染过的浮动标签（
latest/main-latest/main-stable等）； - 能重建的容器 / 节点重建，旧层当可疑资产隔离；
- 临时策略与官方建议一致：钉
litellm==1.106.2，或钉死更早、你已验证过的明确安全版。
步骤 ④ 在干净机器上轮换一切可能摸到的秘密
只要主机曾装过 / 跑过污染产物且有出网，公开口径倾向：假定外泄可能已发生。在干净机器上轮换，至少覆盖：
- 实例 / 任务IAM 角色及相关临时凭证；
- LiteLLM proxy 库里的供应商 Key，以及 master / virtual key；
DATABASE_URL等库连接秘密；- 该主机上任意进程环境变量里的凭据；
- 同机可达的浏览器 / SSH / CI / 包管理器登录态与 token。
建议顺序：先停用高额度 Key → 换新 → 再观察用量，不要「先观察一周再换」。
# 示例：导出当前环境里可疑的 Key 名（仅作盘点，不要把值贴到聊天/工单）env|grep-Ei'API_KEY|OPENAI|ANTHROPIC|AZURE|AWS_|DATABASE_URL|LITELLM'|cut-d=-f1# 然后到各云 / 模型厂商控制台：作废旧 Key → 签发新 Key → 只写入新环境步骤 ⑤ 去供应商后台查用量上限与曲线
供应链投毒落到工程面，常见后果是额度被别人花。同一处置窗口内完成：
- 打开各模型 / 云厂商用量页，对照10-21 窗口前后曲线；
- 给 Key 设用量上限与异常告警；
- 已出现异常尖峰：先停相关 Key，再回头做日志取证。
「查上限」和「钉版本」是同一晚的事，不要拆成两周。
（供应商用量页因账号隐私无法代截：请在本机打开各厂商用量页，对照 10-21 窗口前后曲线，并自行截图归档。）
四、验证清单：怎么证明走完了，而不是「感觉好了」
按行打勾，能截图的尽量留证：
| # | 检查项 | 通过标准 | 结果（自行填） |
|---|---|---|---|
| 1 | 版本 | pip show litellm→Version: 1.106.2（或你钉死的更早安全版），不是1.107.0 | ☐ |
| 2 | 植入物 | 各site-packages根目录无cook.pth/cook.py；无异常sitecustomize.py | ☐ |
| 3 | 残留包痕迹 | 不应再存在litellm-1.107.0.dist-info；搜到即按已暴露处理 | ☐ |
| 4 | 镜像 | 运行中镜像 digest不等于官方披露的污染 image index；浮动标签已改为钉版本 / digest | ☐ |
| 5 | 密钥 | IAM / 供应商 Key / master·virtual key /DATABASE_URL/ CI·SSH 等同机秘密已在干净侧轮换 | ☐ |
| 6 | 用量 | 供应商后台上限与告警已开；窗口前后曲线无未解释尖峰 | ☐ |
快速复检命令（仅在已重建的干净环境或确认植入物已删后使用）：
pip show litellm|grep-iversion# Version: 1.106.2SITE=$(python-c"import site;print(site.getsitepackages()[0])")ls"$SITE"/cook.pth"$SITE"/cook.py"$SITE"/sitecustomize.py2>&1# 期望：No such file or directoryls"$SITE"/litellm-1.107.0.dist-info2>&1# 期望：不存在补充两条官方口径里的「阴性不能当清白」：
- 没找到
cook.*/sitecustomize.py，不能单独证明环境干净（容器与临时目录清理会抹掉痕迹）； - 标记文件存在可作确认信号，不存在同样证明不了什么。
因此对外可说的闭环是：文件系统阴性 + 版本已钉 + Key 已轮换 + 用量无异。
五、边界：这篇能帮你什么、不能帮你什么
适用
- OSS 用户在窗口期内盲升、拉过
latest、或无法排除装过 1.107.0； - 需要一份可抄的：停跑 → 清理 → 重建钉版本 → 轮换 → 查上限；
- 要把「供应链投毒」和「网关权限洞」在 runbook 里拆成两条不同剧本。
不适用 / 易误判
- 企业客户若只从官方私有 registry 拉取，公开口径为未受影响——仍建议确认拉取源，别把「我们是企业版」口头等同于「拉取路径安全」；
- 「在线只有约两小时」≠「风险两小时后自动归零」；
- 在脏 venv 里反复
pip install/pip check当自查，可能再次触发植入物； - 只升级版本、不轮换 Key、不查用量上限，等于只做了闭环的三分之一。
本文明确不做的事
- 不提供 PoC、不写可复现攻击步骤、不展开恶意域名与载荷细节；
- 不把评论区扩成远程排障；需要取证时走你们自己的安全流程与官方通告更新；
- 备案期不放官网死链、不留邮箱 CTA。
主源：LiteLLM 官方事故页Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised。
交叉：Endor Labs、Datadog、JFrog、OSV MAL-2026-2144、Wiz。
配图位仅标注真截图需求，发布前用官方页与本机核对结果替换。
一句话收束：先对上现象 → 停跑并用 shell 清掉cook.pth/cook.py/sitecustomize.py→ 重建并钉litellm==1.106.2→ 干净侧轮换 Key → 去供应商查用量上限；六行验证表全绿再收工。
如果你也在 10-21 窗口碰过未钉版本或latest，按上面清单打勾后，在评论区留一下「本机 / CI / Docker 哪一种」即可（不必贴密钥或内网路径）。
