开源大模型网关框架 LiteLLM 在 2026 年 10 月 21 日发布了 1.107.0 版本。随后安全厂商发现,该版本在 PyPI 上的全部 7 个平台 wheel 安装包以及 Docker Hub 镜像均被植入木马。这并不是简单的第三方依赖撞库,而是一场直击 AI 凭据核心的定向投毒:只要机器装上了这个版本,甚至一次都不需要执行代码导入,宿主机上的云凭据、SSH 密钥和网关存储的商业模型 API 密钥就会被立即打包盗走。

致命的 20 分钟与被污染的流水线

事件发生于 2026 年 10 月 21 日。根据记录,11:39:51 UTC 首个恶意文件上传至 PyPI,到 11:40:13 UTC 全部 8 个文件上传完毕。安全厂商 AISLE 在 11:43:05 标记出首个异常文件,并在 12:00:06 完成全部 7 个 wheel 的标记并推动隔离下架。从发布到被全面标注,整个过程仅持续了约 20 分钟。

全平台投毒包在流水线极速分发,20 分钟内被紧急拦截(示意图)
全平台投毒包在流水线极速分发,20 分钟内被紧急拦截(示意图)
LiteLLM 1.107.0 投毒事件关键时间线 (UTC) 11:39:51 恶意包开始上传 11:40:13 8 个文件上传完毕 11:43:05 AISLE 标记首个异常 12:00:06 全部标记并启动隔离

受污染的不仅是 Python 安装包。Docker Hub 上的官方镜像 litellm/litellm:1.107.0 以及浮动标签 latest、main-latest、main-stable 均在同一时间段被同步污染,随后被官方紧急移除。

网络上一度流传该恶意版本遭遇超过 11.9 万次下载,但这一数据实为 2026 年 3 月 LiteLLM 1.82.7 与 1.82.8 遭受投毒时的历史统计。本次 10 月事件使用了截然不同的攻击载荷与回传基础设施,目前并无证据表明两次事件来自同一组织。

隐蔽执行:不调用库也能失窃的底层机制

常规认知中,只有在代码里执行导入语句才会运行库内逻辑。然而本次攻击利用了 Python 环境长期存在的启动配置机制,将恶意代码植入为 cook.pth 与 sitecustomize.py 两个文件。

无需显式调用,解释器初始化即触发旁路暗格窃密(示意图)
无需显式调用,解释器初始化即触发旁路暗格窃密(示意图)
Python 解释器启动时的静默劫持链条 任意 Python 启动 pip / IDE / 容器进程 完全无需 import litellm site-packages 自动载入 cook.pth 执行窃密 sitecustomize.py 常驻 窃取并回传凭据 模型密钥与云端 Token 加密发送至攻击者域名

Python 解释器在每次初始化时,都会按规范检查并读取第三方目录下的 .pth 路径配置文件和定制模块。通过在 cook.pth 中写入导入指令,攻击者的窃密脚本 cook.py 便能在当前环境启动任何 Python 进程时直接在内存中执行。无论是运行自动化构建、编辑器语言服务还是日常工具,都在触发数据窃取。

攻击载荷 cook.py 经过压缩混淆,解压后体积约为 61 KB。它具有高度明确的针对性:不仅扫描 AWS、GCP 等常规云凭证及本地 SSH 密钥,更定向读取网关的数据库连接串,导出包含各大商业模型 API 密钥的凭证表。采集到的数据经过多层非对称加密后,直接回传至攻击者控制的仿冒域名 www.litellm[.]dev。

守护进程 sitecustomize.py 则通过系统调用脱离父进程,常驻后台运行。该进程每隔一小时尝试从远端 GitHub 地址拉取更新指令,形成了一个具备远程代码执行能力的隐蔽后门。

伪装合规:一条配置穿透 Trusted Publishing

与常见的盗号发布不同,PyPI 官方元数据清晰记录着该版本具备 Trusted Publishing 验证。这项基于 OIDC 的免密发布机制本意是通过受信任的 CI/CD 环境消除长期明文 Token 泄漏的隐患,却在这一次事件中暴露出机制盲区。

免密认证缺少源码校验,合规绿灯反成木马的免检通道(示意图)
免密认证缺少源码校验,合规绿灯反成木马的免检通道(示意图)

构建源头并没有直接在公开的 GitHub 源码分支中提交木马代码。恶意源码压缩包仅仅在打包配置文件中追加了一行 data = "cook"。打包工具 Maturin 据此在编译 wheel 二进制分发包时,顺理成章地将隐藏目录打入 Python 的核心库目录。

现代供应链攻击不再靠粗暴的脚本上传,而是顺着高度自动化的合规管道长驱直入。

StepSecurity 对受感染 Docker 镜像的追踪则暴露出更深的破绽:镜像记录中的代码构建源指向了一个带有微小拼写差异的仿冒组织仓库 Berri-AI/litellm,而合规的官方组织名为 BerriAI。构建流水线 ID 为 39587059944。PyPI 记录显示该版本虽拥有身份核验,但缺少源码溯源证明。

  • 风险.OIDC 机制仅能核验发起请求的工作流身份,但在缺乏强制性源码证明与构建签名锁定的情况下,合规通道同样可能为恶意打包产物颁发信任背书。

网关失守后的架构反思与清理

作为各大模型调度的中心节点,网关框架天生汇聚了企业内部最高权限的模型调用秘钥、组织账号与网络凭证。一旦该层级被穿透,造成的连锁影响往往远大于普通单点应用。

彻底切断受污染网关,全量物理销毁并轮换模型密钥(示意图)
彻底切断受污染网关,全量物理销毁并轮换模型密钥(示意图)

仅依靠包管理器执行卸载操作无法彻底清除风险。残留于环境内的 .pth 文件依然会继续劫持后续的 Python 调用,拉取过未锁定版本镜像的容器集群也需要全面筛查。更关键的环节在于凭证层:所有配置在网关中的云凭据、模型提供商 API 密钥与系统私钥均需立即进行全量轮换。

  • 建议.在生产环境中应当剥离自动安装最新补丁的机制,严格锁定 wheel 哈希值;同时网关层需引入细粒度权限控制与独立的密钥隔离存储,切断单一进程读取全量明文凭据的路径。

这次事件印证了一个残酷的现实:当开发运维流程全面转向自动化发布与流水线集成时,安全防御的重心不能止步于身份认证。如果无法在整个构建链条中对代码来源实施确定性的端到端验证,自动化机制越顺畅,风险扩散的速度也就越快。