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.pyCI / 本机 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 litellmCompose / K8s 是否写着litellm:latest一类浮动标签且可能在污染区间拉过同一台机是否跑着挂有高额度供应商 Key 的 proxy / 自动化任务三个里有一个「是」或「不确定」就按下文完整走一遍三个都是否也建议至少过一遍验证清单别靠感觉。二、原因范围毒在哪、谁在半径里公开案情LiteLLM 官方事故页交叉 Endor Labs / Datadog / JFrog / OSV MAL-2026-2144 / Wiz可压成工程事实2.1 时间窗与产物PyPIlitellm1.107.0约在11:39–13:23 UTC2026-10-21在线约两小时后撤回。Docker Hub / GHCRv1.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。相对安全仍建议过验证表一直钉在litellm1.106.2及更早明确安全版只拉企业私有 registry且能证明拉取源能证明窗口期内未装未跑污染产物。「在线只有约两小时」≠「两小时后风险自动归零」——凭证一旦外泄刷量可以发生在你下班之后。三、分步操作停跑 → 清文件 → 重建钉版本 → 轮换 → 查用量官方处置顺序有点反直觉不要先在怀疑污染的环境里跑pip install。任意 Python 启动包括 pip 自己都可能再次拉起植入物。下面命令按 Linux / macOS 常见路径写Windows 把路径换成你的site-packages即可原则相同。步骤 ① 先停跑服务、定时任务、交互式解释器目标清文件之前尽量不再触发 site-packages 根目录的启动钩子。# 示例按你实际进程名调整# systemdsudosystemctl stop litellm-proxy# 若有同名服务# 或查 Python / litellm 相关进程后结束psaux|grep-Elitellm|uvicorn|gunicorn|grep-vgrep# 停掉相关 cron / CI runner 上的并发任务后再继续有公开通告提到的、持有异常锁文件的后台进程与远程加载相关时先杀进程再删文件。步骤 ② 定位 site-packages用 shell 删植入物不要先 python先找出可能的site-packagesvenv、系统、用户路径都要看# 列出常见 site-packages在「尚未确认干净」时尽量用 shell少启 pythonls-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仍避免 pythonfind/-namecook.pth-o-namecook.py2/dev/null|head-50find/-namesitecustomize.py2/dev/null|head-50用 shell / 文件管理器直接删不要先python -c import ...去探测。容器内路径同理进到可写层或重建前把上述文件清掉。步骤 ③ 重建环境钉死litellm1.106.2优先新建干净 venv或新机器不要在脏环境里「覆盖安装」指望一次到位# 在确认已清植入物、或全新机器上执行python-mvenv .venv-cleansource.venv-clean/bin/activate pipinstall--upgradepip pipinstalllitellm1.106.2pip show litellm# 期望Version: 1.106.2依赖文件示例二选一原则是永远带版本号# requirements.txt litellm1.106.2# pyproject.toml 片段示例 # dependencies [ # litellm1.106.2, # ]Docker / Compose 侧# 不要# image: ghcr.io/berriai/litellm:latest# 要显式版本或你已核对过的 digestimage:ghcr.io/berriai/litellm:v1.106.2# 或# image: ghcr.io/berriai/litellmsha256:你核对过的干净 digest不要再盲信曾被污染过的浮动标签latest/main-latest/main-stable等能重建的容器 / 节点重建旧层当可疑资产隔离临时策略与官方建议一致钉litellm1.106.2或钉死更早、你已验证过的明确安全版。步骤 ④ 在干净机器上轮换一切可能摸到的秘密只要主机曾装过 / 跑过污染产物且有出网公开口径倾向假定外泄可能已发生。在干净机器上轮换至少覆盖实例 / 任务IAM 角色及相关临时凭证LiteLLM proxy 库里的供应商 Key以及 master / virtual keyDATABASE_URL等库连接秘密该主机上任意进程环境变量里的凭据同机可达的浏览器 / SSH / CI / 包管理器登录态与 token。建议顺序先停用高额度 Key → 换新 → 再观察用量不要「先观察一周再换」。# 示例导出当前环境里可疑的 Key 名仅作盘点不要把值贴到聊天/工单env|grep-EiAPI_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-cimport site;print(site.getsitepackages()[0]))ls$SITE/cook.pth$SITE/cook.py$SITE/sitecustomize.py21# 期望No such file or directoryls$SITE/litellm-1.107.0.dist-info21# 期望不存在补充两条官方口径里的「阴性不能当清白」没找到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→ 重建并钉litellm1.106.2→ 干净侧轮换 Key → 去供应商查用量上限六行验证表全绿再收工。如果你也在 10-21 窗口碰过未钉版本或latest按上面清单打勾后在评论区留一下「本机 / CI / Docker 哪一种」即可不必贴密钥或内网路径。