LiteLLM 1.107.0 投毒排查实战：依赖、Docker、CI 环境分别怎么查？

10 月 21 日，LiteLLM 发布流程遭到攻击，恶意版本 1.107.0 被发布到 PyPI，部分容器镜像也受到影响。

如果你的项目使用了 LiteLLM，眼下最重要的不是马上升级，而是先弄清楚：有没有在受影响时间窗口内安装或运行过问题制品？相关环境能够访问哪些密钥？

本文按开发者常见的三种环境展开：Python 项目、Docker 部署和 CI 流水线。

一、先判断自己是否处于影响范围

使用情况	建议
依赖明确锁定在 `1.106.2` 或更早版本	按官方通告核对后，通常不属于本次受影响版本
10 月 21 日安装过未锁版本的 LiteLLM	核对安装记录和实际解析出的版本
当晚拉取过 `latest`、`main-latest` 等镜像标签	核对历史镜像摘要和部署记录
CI 在受影响窗口内重新安装依赖或构建镜像	检查构建日志和产物来源
只查看当前标签，没有保存历史摘要	不能仅凭当前标签还原当时使用的制品

官方公布的时间窗口均为 10 月 21 日 UTC：

PyPI 的 litellm==1.107.0：11:39---13:23；
Docker Hub 的受影响标签：11:46---14:20；
GHCR 的受影响标签：11:46---13:51。

对应北京时间分别为 19:39---21:23、19:46---22:20 和 19:46---21:51。

官方建议目前固定到 1.106.2 或更早的明确版本。发布前请再次核对官方通告是否有更新。

二、Python 环境：先查文件，不要先跑 pip

恶意版本包含 cook.pth、cook.py 和 sitecustomize.py 等文件。.pth 文件中的特定导入语句可能在 Python 启动时执行，而 pip 本身也是 Python 程序。

因此，在疑似受影响的环境中，不要把 pip show、pip install 或运行 Python 作为第一步。

可以先通过系统命令检查：

bash 复制代码

find / -path /proc -prune -o \
  ( -name 'cook.pth' \
  -o -name 'cook.py' \
  -o -name 'litellm-1.107.0.dist-info' ) \
  -print 2>/dev/null

再查看已知临时标记：

javascript 复制代码

ls -d /tmp/remote_code_loader.lock \
  /tmp/.pc_once_* /tmp/.pc_sq_* /tmp/.pc_e_* \
  2>/dev/null

这里要区分两种结果：

发现相关文件： 这是重要的受影响线索，应按问题环境处理。
没有发现文件： 不能据此认定环境安全。临时目录可能被清理，容器也可能已经销毁。

如果主机上同时运行多个 Python 项目，要检查实际部署环境中的相关包目录，而不只是当前终端所处的虚拟环境。

三、Docker：为什么要看摘要而不是标签？

容器标签只是一个便于使用的名称，可以被重新指向其他镜像。摘要用于标识具体的镜像内容，更适合追溯历史制品。

先查看本地镜像：

css 复制代码

docker images --digests \
  --format '{{.Repository}}:{{.Tag}} {{.Digest}}'

再将结果与 LiteLLM 官方通告中的受影响摘要逐项对照。官方公布的主镜像摘要以 1bbcb1443bc9 开头；另外两个相关镜像也有各自的受影响摘要前缀，不能只核对主镜像。

如果本地镜像已经删除，应继续查：

镜像拉取和部署记录；
容器编排文件及其历史版本；
构建产物清单；
镜像仓库的推送、拉取记录。

只看到当前的 latest 标签指向干净镜像，并不能说明之前运行过的容器也没有受到影响。

四、CI：任务结束后，重点看构建记录

CI 环境通常是临时创建的。任务结束后，文件系统可能已经销毁，本地无法再找到相关痕迹。

在 10 月 21 日的相关任务中，重点搜索：

依赖安装日志中是否出现 litellm==1.107.0；
构建任务使用了哪个仓库和提交；
容器构建是否拉取过受影响的基础镜像；
任务当时能够读取哪些环境变量和部署凭证。

如果问题版本在 CI 任务中运行过，就需要按该任务可访问的凭证范围进行排查。即使没有发现恶意文件，也不能因此跳过凭证轮换。

五、确认受影响之后怎么恢复？

建议按下面的顺序处理。

1. 隔离并重建

先停止相关任务或服务，保留必要的日志和部署记录。不要把删除几个文件视为完整恢复；官方更建议从干净环境重新构建虚拟环境或容器。

2. 固定版本和制品

目前按官方建议固定到 litellm==1.106.2 或更早的明确版本。依赖锁文件可以进一步记录哈希，安装时进行校验；容器部署则应固定到已核验的摘要，而不是长期依赖浮动标签。

3. 更换可能暴露的密钥

重点包括模型服务商密钥、LiteLLM 主密钥和虚拟密钥、数据库密码、云端身份凭证，以及主机上的 Git、SSH、软件包发布和其他部署凭证。

在干净的机器上签发新凭证，替换后及时吊销旧凭证。

4. 检查审计日志

如果相关环境使用 AWS 身份凭证，应检查 CloudTrail 中的 GetCallerIdentity 等事件，并关注是否出现来自基础设施之外的异常调用。实际排查范围应结合部署时间和使用区域确定。

六、这次事件值得留下的三个工程习惯

第一，依赖版本必须可追溯。 生产环境不要依赖未锁定的依赖声明；锁定版本后，再考虑哈希校验和制品来源验证。

第二，CI 凭证应按任务授权。 构建任务只应获得完成当前工作所必需的权限，发布凭证与普通测试任务分开管理。

第三，日志不能默认保存所有内容。 运行日志尽量记录排障所需的元数据。请求和响应正文可能包含令牌或其他敏感信息，确需记录时应先脱敏并限制访问。

这次事件的教训并不是"某个包不能用了"，而是依赖、构建、发布和运行环境需要形成一条可核验的信任链。对开发团队来说，能够回答"安装的是什么、从哪里构建、运行时能访问什么凭证"，比单纯追踪版本号更有价值。

参考： LiteLLM 官方安全通告

docs.litellm.ai/blog/securi...