LiteLLM 1.107.0 遭供应链投毒：凭据窃取与后门处置指南

事件概述：不到两小时的窗口期，足够造成持久风险

开源大模型调用网关 LiteLLM 的 PyPI 包 1.107.0 版本在发布后不到两小时内被确认包含凭据窃取代码与后门逻辑，随后被下架。这类供应链投毒事件的关键不在于暴露时长，而在于两点：一是恶意版本被安装的概率，二是安装之后凭据泄露的不可逆性。两小时足以被 CI/CD 流水线、镜像自动构建和依赖锁文件更新捕获，而 API 密钥一旦外泄，攻击者并不需要持续驻留即可长期使用。

本文基于官方披露信息与社区验证结果，梳理三个动作：确认是否受影响、清理本地与构建环境、轮换已暴露凭据。对使用 LiteLLM 作为多模型统一入口的团队，这是一次必须按安全事件响应流程处理的问题，而不是一次普通升级。

先确认影响面：谁可能装到了恶意版本

版本与安装渠道的判定

受影响的是 PyPI 上发布的 1.107.0。需要排查的不只是直接 pip install litellm 的开发者环境，还包括：

锁定文件或依赖解析结果恰好落在 1.107.0 的项目（含间接依赖）
在事件窗口内重建过的容器镜像与 CI 构建产物
内部私有源、制品库中缓存或镜像的该版本
使用自动升级策略的开发机与实验环境

检查方式以 pip show litellm、pip freeze | grep litellm 或项目锁文件为准，容器环境需进一步检查镜像层中的实际安装版本，而不是只看构建脚本声明。

供应链投毒（Supply Chain Poisoning） 指攻击者通过篡改软件分发链条中的合法组件（如公共包索引上的发布包、构建工具、依赖库）来植入恶意代码，而非直接攻击目标系统。与传统的漏洞利用不同，投毒依赖的是开发者对上游组件的信任：只要有人安装或拉取被污染的版本，恶意代码就会在正常构建或运行流程中自动执行。PyPI、npm 等公共仓库因其开放发布机制，成为此类攻击的高发地带。防御重点在于锁定依赖版本与校验哈希、延迟引入新发布版本、以及对关键依赖的变更进行审计，从而缩小“发布窗口期”被自动捕获的概率。

为什么"升级到新版本"不等于安全

恶意代码已经执行过，升级只是阻止后续执行，不消除已发生的凭据读取。因此排查顺序应是先取证、再清理、最后轮换，避免在取证前覆盖证据。实际处置中，优先记录受影响主机、镜像与构建流水线的清单，作为后续轮换范围的依据。

清理优先级：从凭据到环境

第一优先级：轮换所有可能被读取的密钥

LiteLLM 的定位决定了它能接触到大量高价值凭据：各家模型厂商的 API Key、代理服务的访问令牌，以及部署环境中注入的其他环境变量。凭据窃取型恶意代码通常直接读取环境变量与配置文件，因此轮换范围应以"该环境中存在过什么"为准，而非"LiteLLM 理论上需要什么"。

轮换清单建议覆盖：模型服务商 API Key、云厂商访问密钥、数据库与缓存连接串、内部服务间令牌、CI/CD 平台密钥、以及任何在受影响环境中出现过的第三方 Token。轮换后需同步检查各平台的用量与调用日志，寻找异常调用来源，尤其是原本不会出现的出口 IP 或调用模式。

凭据轮换（Credential Rotation） 是指在怀疑或确认密钥泄露后，废止旧密钥并签发新密钥，使已外泄的旧值失效。对于凭据窃取型恶意代码，轮换是唯一能切断攻击者长期访问的手段——因为攻击者往往在窃取后离线使用密钥，不依赖持续驻留。轮换应遵循“宁可过度覆盖”的原则：以受影响环境中实际出现过的密钥为范围，而非组件理论上需要的密钥。轮换后必须配合调用日志审计，检查是否存在来自异常 IP、异常时段或异常调用模式的请求，以确认泄露是否已被利用，并据此决定是否需要进一步扩大轮换范围。

第二优先级：重建而非修补环境

对确认安装过恶意版本的机器与镜像，建议直接重建。后门逻辑的存在意味着攻击者可能具备进一步的下发能力，清理单个文件不足以恢复可信状态。涉及范围包括开发机、构建节点、容器镜像与任何运行过该版本的测试环境。同时清理包管理器缓存与私有制品库中的对应版本，防止回滚时再次引入。

后门（Backdoor） 指攻击者植入的、用于绕过正常认证或持续获取控制权的隐蔽机制。与一次性的凭据窃取代码不同，后门可能包含远程下发指令、定时回连或二次载荷加载的能力。这意味着即使删除了已知的恶意文件，攻击者仍可能通过其他残留机制重新获得访问。因此，对确认运行过含后门版本的环境，安全处置的标准做法是“重建而非修补”：从可信基线重新部署，彻底丢弃可能被篡改的系统和镜像，并清理制品库中的对应版本，防止回滚或缓存再次引入。

第三优先级：收紧依赖策略

事件暴露的是通用问题：直接依赖公共包索引且允许自动解析最新版本，会把发布窗口期的风险直接传导到生产链路。可行的改进包括使用带哈希校验的锁定文件、为关键依赖设置内部审计与延迟引入策略、对新增依赖变更做人工或自动化审查。对 LiteLLM 这类处于调用链中心位置的组件，还应限制其运行环境可访问的密钥范围，通过最小权限降低单点泄露的爆炸半径。

对 AI 工程栈的启示

网关类组件是供应链攻击的高价值目标

LiteLLM 这类统一接入层天然持有多个供应商的凭据，并且通常部署在能访问内网与外部 API 的位置。攻击者选择它并非偶然：一次成功的投毒可同时获取多家模型服务的访问权，且这类工具在可观测性上往往弱于核心业务服务。团队在引入此类工具时，应将其视为敏感基础设施，适用与数据库、密钥管理服务同级的安全要求。

需要可执行的检测与响应能力

本次事件中，版本号是唯一可靠的判别信号，这本身就说明问题：如果缺少依赖清单、构建溯源与凭据使用审计，团队很难在事后界定影响边界。更现实的做法是把"依赖变更检测"和"凭据使用异常检测"纳入日常监控，使类似事件的响应从"排查数天"缩短到"按清单执行"。

行动清单

检查所有环境与镜像中的 LiteLLM 版本，标记 1.107.0 的命中项。
对命中环境中的全部凭据执行轮换，并审计各平台调用日志。
重建受影响主机与镜像，清理制品库中的对应版本。
强化依赖锁定与审计流程，缩小网关组件的密钥访问范围。

供应链投毒的处置原则并不复杂：把它当作已发生的凭据泄露事件处理，而不是一次需要回滚的版本升级。