LiteLLM 1.107.0被植入恶意代码，降回旧版还不够

如果你平时只是在网页或客户端里用大模型聊天，这次事件和你没有直接关系，不需要慌慌张张去把所有账户密码换个遍。

出事的是 LiteLLM，一个很多开发者和团队用来集中调度、调用各大模型接口的开源工具。官方通报显示，他们的发布流程遭到了入侵，版本 1.107.0 里被塞入了窃取凭据和远程代码执行的恶意文件。受影响的安装包目前已经被官方移除，私有企业发布版没有受到波及。

先对时间线：核对当时拿到的版本

受影响的是在特定时间窗口内拉取过该版本的开发和部署环境。对应到北京时间，主要集中在 10 月 21 日晚间：

• PyPI 的 wheel 安装包：10 月 21 日 19:39:51 至 21:23 期间，共有 7 个 wheel 包提供过下载。
• Docker 镜像：19:46 至 22:20 期间（以 Docker Hub 下架时间为准，GHCR 移除得更早），除了明确写着 `v1.107.0` 的镜像，打着 `latest`、`main-latest`、`main-stable` 这些浮动标签的镜像也全都落在这个区间。

已经下载到本地的恶意安装包，稍后安装仍有风险。凡是在这个时间段内跑过自动化构建、更新脚本，或者拉取过上述浮动标签的人，都得去查当时实际拿到的版本。

为什么光降级没用？

不少人发现依赖出问题，习惯敲一行 `pip install litellm==1.106.2` 降回去继续跑。在这次事件里，直接敲这行命令非但解决不了问题，还会把问题再触发一遍。

JFrog 的安全研究员 Guy Korolevski 和 Endor Labs 的研究员 Peyton Kennedy 在独立比对中都指出了同一个机制：恶意代码直接跟安装包潜入 Python 环境，挂在启动钩子上。只要在受影响的环境里启动 Python，恶意代码就会执行。哪怕你的业务代码里根本没有写过 `import litellm`，只要在环境里运行一下 `pip`，它同样会被触发。

只看代码仓库也看不出破绽。官方 GitHub 仓库打出的源码 tag 里是干干净净的，恶意发布包来自名字极为相似的攻击者仓库。仅凭 GitHub 源码判断安装包是否安全，在这里直接失效了。

更关键的是，官方要求按密钥已经外泄来处理。Endor Labs 指出，恶意程序专门定向搜集 LiteLLM 存储的模型服务商凭据；JFrog 的分析也证实，包括云凭据、开发工具配置、浏览器存储和进程能读到的环境变量，都会被它读取。

只要装有恶意版本的主机连过网，官方要求按这些钥匙已经外泄来处理。在本地把软件退回旧版本，根本不会让已经外泄的密钥失效，也无法保证后台没有残留的恶意进程。

正确的处置顺序：从环境外部处理

官方给出的建议非常直接：把跑过 1.107.0 的机器当成完全不可信的环境，不要在里面碰 pip，直接推倒重建。

第一步是停机排查。停止所有受影响的进程，从受影响环境的外部去核对安装日志与版本记录。Endor Labs 和 JFrog 都提到，临时文件和容器被销毁时可能会自动清空，缺少标记文件不能证明机器安全，排查要结合安装记录和文件证据。

第二步是彻底重建。移除恶意的启动文件和后台进程，在干净机器或新镜像里重新部署，优于在原环境里修修补补。干净环境里的版本要明确固定在 1.106.2 或其他已确认安全的版本上，不要图省事继续用浮动标签。

第三步是撤销并轮换所有钥匙。

只要 1.107.0 在可联网的环境里运行过，必须撤销并更换该环境能接触到的所有模型服务商密钥、云访问权限、数据库密码和其他 Secret，同时去各服务商后台排查当时的调用日志，核对有没有异常账单和未授权请求。

换密钥的操作顺序千万别搞反

换钥匙这件事，顺序做错等于白做。

操作必须在另一台确认干净的机器上进行：登录服务商控制台，撤销旧钥匙，换上新钥匙；等确认受影响的环境已经彻底清理、重建成干净系统后，再把新钥匙放进去。如果原机器还没清理完就在上面改配置，新换上去的密钥同样会被抓走。

对于只用客户端和大模型聊天的普通用户，这次事件不需要跟着全网改密码；但如果是自己跑 LiteLLM 服务的开发者，排查到那几个小时里拉过受污染的版本，就别抱侥幸心理，照着停机、重建环境、在外部换钥匙的顺序处理完才算真正收工。