LiteLLM 用户先别急着轮换密钥：半年两起事件、三个误区、一张分级自查表

跑 LLM 网关的朋友，如果你这周在安全资讯流里看到「LiteLLM」心里咯噔了一下，先别慌，也别立刻去把所有密钥轮换一遍。这几天我把 CloudSEK、Hudson Rock 的完整报告、360 的漏洞通告和国内几篇复盘文都翻了一遍，今天用一篇说清楚：到底发生了什么、谁才真的需要紧张、谁只需要花十分钟自查。

先说这周发生了什么：两件事撞到一起

第一件，8 月 11 日，安全厂商 CloudSEK 和 Hudson Rock 联合发布了「3·24 LiteLLM PyPI 投毒事件」的完整复盘报告，首次公开了泄露凭证的规模：超过 2500 家企业、约 43.4 万条 CI/CD 流水线存在暴露风险。知乎受影响名单里包括亚马逊、三星、思科等公司。哔哩哔哩

第二件，几乎同一时间，国内安全圈集中传播一组 LiteLLM 漏洞链：CVE-2026-47101、47102、40217，组合评分 CVSS 9.9，修复版本 v1.83.14-stable。知乎三个漏洞串联后，网关里的一个普通用户可以一路提权到管理员，把网关里存的所有模型厂商 API Key 读出来。

一件是三月旧案的「补账」，一件是眼下就要打补丁的「现行风险」。很多文章把两者混着写，越写越吓人，但两件事的应对动作完全不同。

先给不了解背景的朋友补一句：LiteLLM 是目前最主流的开源大模型网关之一，它用一套 OpenAI 兼容接口统一对接上百家模型厂商，顺带管理虚拟密钥、预算和负载均衡——也正因如此，它成了攻击者眼中的「高价值钥匙库」。当时 Karpathy 专门发长推文警告全部开发者，注意这个 GitHub 星标超过 4 万、月下载量达 9700 万次的库。36氪连马斯克都被这件事惊动，在推下留言提醒风险自担。

半年时间线，一张表看完

三个关键点：投毒是「当时装过那两个版本才中招」，漏洞链是「现在还在跑低版本才有风险」；八月这份报告是给前者补账，不是又发生了一次新的投毒。这场投毒事件的攻击链、根因和防护要点，已经有开发者整理成了一张总览图，先看结构再看细节：

三个反常识，第一个最容易误解

入口是你以为最安全的漏洞扫描器。 八月报告还原的完整攻击链是：攻击组织 TeamPCP 在 3 月 19 日先攻陷 Trivy（业界主流漏洞扫描工具），再借这把被污染的扫描器偷走 LiteLLM 的发布令牌。哔哩哔哩CI 流水线普遍对安全工具自动更新、不锁版本，恶意 Trivy 就这样潜入了 LiteLLM 官方构建流水线，抓走维护者的 PyPI 发布 Token。知乎攻击者潜伏 20 天后，才在 3 月 24 日上传了投毒的 v1.82.7 和 v1.82.8。

恶意包是「自己炸了」才暴露的。 投毒的 v1.82.8 把后门藏在 litellm_init.pth 文件里——Python 有个机制，site-packages 目录下的 .pth 文件会在每次解释器启动时自动执行，不需要 import、不需要任何触发。知乎本来近乎完美隐身，但恶意代码的子进程会再次触发 .pth，无限递归，直接把一位 FutureSearch 工程师的笔记本跑出 1.1 万个进程当场卡死，他顺着排查，从第一个症状出现到完成公开披露只用了 72 分钟。知乎

按复盘材料的说法，恶意版本在 PyPI 上只存活了约 40 分钟。哔哩哔哩但对 7×24 小时自动构建的流水线来说，40 分钟足够大面积扩散。Karpathy 事后说，如果攻击者编程能力再强一点，可能几周都不会有人发现。社区里有人调侃，这次是「vibe coding 救了大家」——恶意代码的开发者采用了 AI 编码，才留下这种低级 bug。36氪

没装过 ≠ 无关，卸载 ≠ 安全。 很多上层框架（LangChain、Dify 这类）会把 LiteLLM 当间接依赖，构建时递归安装，你自己的代码里搜不到它也照样中招。知乎而投毒包的核心危害是把凭证打包外传——SSH 密钥、云厂商凭据、K8s Token、.env、shell 历史、甚至加密钱包，用 RSA 加密后发往攻击者控制的域名。知乎包下架了、版本升级了，被偷走的凭证依然长期有效。所以「把 litellm 卸载了」是这次事件里最没用的补救动作。

对照自查：你属于哪一档

两个判断依据说明一下：第一档的风险窗口只看 3 月 24 日投毒版本上架的那段窗口期，之后安装的正常版本不受影响；第二档之所以危险，是因为这轮漏洞链的利用前提，就是攻击者手里有一个普通用户的 Key。知乎网关开的用户越多、接口越对外，被串起来的概率越大。

自查的第一步很简单，在你的环境里执行 pip show litellm，确认当前版本号和安装来源：

间接依赖可以用 pipdeptree 这类工具反查，看看是谁把 litellm 带进来的。

真中招了，按这个顺序做

如果你的构建环境在窗口期跑过，别抱侥幸，按顺序执行：

1. 全量轮换凭证：云厂商 AccessKey、GitHub / GitLab Token、PyPI / npm 发布密钥、所有大模型 API Key、SSH 私钥、K8s Secret、数据库密码，一个都不能少。知乎

2. 重建构建环境：清掉 Runner 的容器、镜像和依赖缓存，重新初始化。后门靠 .pth 持久化，只卸载包不会消失。

3. 审计操作日志：核查轮换前各类凭证的登录与调用记录，确认没有异常外访或越权操作。

4. 锁版本 + 哈希校验：依赖写死具体版本号，pip 开启 require-hashes，废掉「自动拉最新」。

如果只是跑 Proxy 服务，动作更简单：升级到 v1.84.0-rc.1 或更高版本，一个版本同时覆盖 CVE 漏洞链（修复版本 v1.83.14-stable）和 Pwn2Own RCE 链的修复入口。知乎知乎顺手检查管理端口和 /user/update 接口有没有裸奔在公网。下面这张漏洞链推演图，值得转发给你们管网关的同事看看：

还有一个零成本小检查：在你的 Python 环境 site-packages 里搜 litellm_init.pth。正常官方版本没有这个文件，存在即异常。升级前去官方 GitHub 确认一下最新稳定版号，以官方发布为准。

要不要换网关？别慌，但这课值得补

事件之后，社区里「替代网关」的讨论又热了一轮：Go 写的 Bifrost 主打比 LiteLLM 轻、并发高，也有人提 new-api、OmniRoute。哔哩哔哩

两点说清楚：第一，这次是供应链问题——攻击者劫持的是 PyPI 发布凭证，换成任何 PyPI 上的其他包，这类风险面一样存在，换网关解决不了；第二，LiteLLM 官方正在把核心运行时从 Python 迁移到 Rust，目标是超轻量、高性能的底层架构，被吐槽最多的性能和内存占用问题，后面可能会有变化。哔哩哔哩

我的判断：除非你本来就被性能或资源占用卡住了，否则不必恐慌式迁移。但值得借这次机会把三件事变成团队习惯——依赖锁版本、构建开哈希校验、核心凭证定期轮换。这比换任何网关都实在。

三个值得继续盯的信号

1. CloudSEK / Hudson Rock 公开的泄露凭证数据集里是否涉及你自己的组织，报告给出了排查入口；

2. LiteLLM v1.84 稳定版的正式发布节奏，以及 Rust 重写版的落地时间；

3. PyPI 和主流 CI 平台会不会跟进更强的发布校验机制，这次事件后社区呼声很高。

安全这件事，恐慌来的时候，先分清风险是「历史的」还是「现行的」，再决定是轮换密钥还是升级版本。希望这篇帮你省下一下午的排查时间。