LiteLLM被投毒后,别只卸载那个包

装 AI 工具时，很多人最熟悉的动作是复制安装命令。出了问题，最顺手的动作则是卸载，再换个版本。

但这次 LiteLLM 的事，麻烦恰恰在这里：你可以把有问题的软件拿掉，却收不回已经被复制走的密钥。

我把维护者通报、GitHub 原始报告和 Wiz 的分析对照了一遍。最值得先记住的判断是：停止恶意程序继续运行，和让泄露的访问凭据失效，是两件都要完成的事。

前一件处理机器里的东西，后一件处理别人手里那张还可能有效的“通行证”。只做其中一件，都容易留下尾巴。

图：LiteLLM 官方通报确认，10 月 21 日的 v1.107.0 发布产物遭到污染。

这篇想解决的，不是让你再记住一个安全事件名字，而是下次看到“某个 AI 依赖被投毒”时，知道先停哪一步、找什么证据、什么时候才算可以恢复使用。

先分清，你接触的是哪一个版本

LiteLLM 常被用来统一接入不同模型服务。有些人直接安装它，有些人则是安装别的 AI 项目时，由依赖关系把它一起带进环境。你不记得自己主动装过，并不能替代安装记录。

这次官方确认的重点是 Python 包 litellm==1.107.0，以及事件窗口内受影响的容器镜像。latest、main-latest、main-stable 这样的浮动标签也曾指向受污染产物。

注意“事件窗口内”这几个字。现在同名标签指向的内容可能已经变了，判断过去有没有拉到问题镜像，要看当时的镜像摘要和部署记录，不能只看今天界面上的版本名。

也别反过来，把“用了 LiteLLM”直接等同于“已经中招”。先把实际安装版本、下载或构建时间、运行过的环境列出来，才谈得上判断范围。

如果是公司项目，我会先向维护人要四样信息：锁文件或依赖清单、安装构建日志、实际运行的镜像摘要、发生过升级的时间。比起一句“我们应该没用那个版本”，这些记录更能支撑下一步。

如果只是下载了一个镜像，尚未运行，也要把“拿到了文件”和“执行了其中的程序”分开记录。不要为了验证能不能启动，又把它运行一遍。

最反常识的一步：先别在可疑环境里跑 pip

平时查包版本，用 pip 很自然。可这次，确认或怀疑环境受影响以后，这个习惯需要先停一下。

官方通报的处置章节专门提醒：不要一上来就在受影响环境中执行安装操作，因为启动那里的 Python，也可能再次触发恶意启动文件；pip 本身也属于这个范围。

图：官方处置章节提醒，受影响环境中的 Python 启动可能再次执行恶意文件，包括运行 pip。

为什么不是非得写了 import litellm 才有风险？因为 Python 的启动过程本来就有加载环境配置的机制。.pth 中的特定代码行、sitecustomize 等入口，可以在你的业务代码开始前被处理。Python 官方说明写清了这类启动行为。

这次攻击利用的就是这条路。对受影响环境而言，“我还没正式用它问过模型”并不是一个可靠的安全结论。

因此，先从现成的锁文件、构建记录和部署日志查起。需要进一步检查磁盘证据时，让维护者从可信环境操作，而不是在可疑环境里一遍遍启动解释器。

同样，不要看到网上列了几个文件名，就在自己的所有 Python 环境里批量删除同名文件。文件位置、内容、版本和运行历史要一起核对，公司的服务还需要保留调查证据。

卸载处理的是程序，撤销处理的是权限

Wiz 的分析指出，恶意程序面向的并不只有某一家模型平台的 API Key，还包括云服务、开发工具和浏览器等凭据。问题范围取决于那个环境实际能读取到什么，不能只围着软件名字里带的“AI”两个字找。

想象你给一个自动化服务放过模型密钥、数据库连接信息和代码仓库访问令牌。即使有问题的依赖后来被删除，这些凭据也不会因为文件少了一个，就自动在各个平台失效。

这就是我会把处置拆开的原因。

先控制受影响环境。 暂停相关任务，由负责的人按应急流程隔离、保留必要证据，并确认后台进程和启动入口的处理范围。不要急着用“重新装上能跑了”来宣布结束。

再从干净设备处理访问凭据。 列出环境能接触到的模型服务、云平台、数据库、代码托管以及其他授权。按各自服务的应急流程撤销或轮换，检查相关会话；不要只改一个登录密码，就默认所有 API Key 和令牌都被收回了。

比如 GitHub 的 OAuth 应用授权，有单独的查看与撤销入口：Settings → Applications → Authorized OAuth Apps。官方操作说明可以对照着看。个人访问令牌、SSH 密钥等则按各自类型另行处理，不能混为一个按钮。

云服务同样需要检查访问记录。以 AWS 为例，官方建议用 CloudTrail 监控访问密钥的使用情况。密钥管理说明里有相应入口。暂时没有异常记录，不等于一把可能泄露的旧密钥可以继续留着。

最后才恢复工作。 确认受影响主机及持久化问题得到处理后，从可信产物重建环境，把新凭据只放进确认干净的环境。仅重建一个虚拟环境，并不能替你证明整个宿主机已经干净。

这三步处理的是不同对象：机器、权限和恢复。把它们揉成一句“卸载重装”，最容易漏掉中间那件事。

让 AI 帮忙整理，不要把密钥再交给它一次

这类事件里，AI 仍然能帮上忙，但适合先做材料整理。

你可以给它不含秘密的依赖清单、版本号、时间线，让它把已确认事实、缺少的证据和待办分开。例如：

只分析这份脱敏依赖与部署记录，列出需要核实的环境、版本、运行时间和凭据类别。证据不足的标成未知。先生成处置清单，任何启动程序、删除文件、修改授权或替换凭据的动作都留待确认。

这里给的是凭据类别，比如“模型平台 Key”“数据库账户”，不是真实值。也不需要为了让 AI 看得更完整，把整份环境变量、配置目录和原始调试日志都贴进去。

一张够用的清单，可以只保留：环境名称、实际产物版本或摘要、是否运行、能读取的凭据类别、负责人、当前处理状态。它的作用是避免漏项，不能自动给机器签发一张“已安全”的证明。

还有一个容易混淆的地方：锁定版本或镜像摘要，能帮助你控制变更、复现当时运行的内容；但如果锁定的本来就是被污染的产物，锁得再牢也不会把它变干净。来源、构建链和更新流程仍然要有人负责核验。

这次最值得留下的习惯，可能不是以后永远不更新，而是让“装软件”和“交权限”重新变成两件清楚的事。试用环境少放凭据，正式环境保留产物记录，出事时按范围处理，恢复时确认旧权限已经失效。

程序可以卸载，泄露的权限需要另外撤销。真正的收尾，是两边都关上。

事件来源：LiteLLM 官方通报 · GitHub 原始报告与更新 · Wiz 技术分析