LiteLLM 供应链后门事件：3 小时暴露窗口，为何 AI Agent 网关成了高风险单点
2026 年 3 月 24 日，LiteLLM 的两个带后门版本被发布到 PyPI，暴露窗口约 3 小时。攻击者没有改动源码，而是从 CI 流水线中窃取了发布凭据——一款安全扫描工具反而成了入侵入口。对任何把 LiteLLM 当作 Agent 网关的团队来说，这次事件的处置粒度不是“重装包”，而是“换主机、换凭据”。
事件经过：两个版本，一个不确定的时间窗
2026 年 3 月 24 日，LiteLLM 的两个带后门版本先后被上传到 PyPI：1.82.7（10:39 UTC）与 13 分钟后的 1.82.8（10:52 UTC）。
关于暴露时长，目前有两个版本的说法。据 NHS England 的网络警报，PyPI 在当日 13:38 UTC 隔离该包，窗口约 3 小时；LiteLLM 自己的事件博客则称约 40 分钟。两条时间线未能完全对齐，因此精确时长应视为不确定。
这个包的体量值得注意：LiteLLM 月下载量超过 9500 万次，且通常被部署为 AI Agent 与多家模型供应商之间的网关。
攻击路径：被攻陷的 CI 流水线，而不是源码
攻击者 TeamPCP 并未改动 LiteLLM 源码。他们通过 CI 流水线中被攻陷的 Trivy GitHub Action 窃取了 PyPI 发布凭据——也就是说，一款用于安全扫描的工具，本身成了入侵入口。
这一点对防御思路的启示很直接：供应链防御的重心应放在 CI 凭据与流水线权限上，而不只是代码审查。
两个版本的载荷投放方式不同，风险级别也不同：
- 1.82.7 将恶意代码注入
proxy_server.py，在导入 proxy 模块时触发。 - 1.82.8 进一步加入
litellm_init.pth。.pth是 Python 环境启动时会自动加载的配置文件，这类文件在该环境内任何 Python 解释器启动时即执行，无需import litellm。
这意味着“有没有调用这个库”不再是风险判断依据。暴露面等于该环境中的所有 Python 进程，而 Agent 栈常见的定时重启，恰恰会成为外泄的触发点。
载荷会收集 SSH 密钥、云凭据、Kubernetes token、数据库凭据、加密钱包与各家 LLM API key，并写入可跨重启存活的持久化机制。Sonatype 将其追踪为三阶段窃取器（编号 sonatype-2026-001357，Python 侧编号 PYSEC-2026-2）。
事后处置方面，PyPI 最终隔离了整个 litellm 项目的全部版本；LiteLLM 确认 Trivy 入侵已受控，受影响版本已删除。
为什么网关被攻破，后果远大于普通库
网关在架构上是天然的收敛点：所有 Agent 到所有模型的调用都经过它，各家供应商的 API key 集中在它这里，限流与日志所用的数据库连接串也由它持有。
所以攻破一个网关，等于继承整个租户的权限，而不是拿到某个单点功能。这也是 AI 编程工具链里一个容易被低估的事实：大家盯着模型和 Agent 框架，真正握着全部钥匙的往往是中间那层网关。
风险还被 Agent 栈的几个结构性习惯放大：长生命周期进程按自己的计划重启、跨项目复制且未锁定版本的 requirements.txt。一旦版本为 1.82.7 或 1.82.8 且在 3 月 24 日及之后安装，应直接视为失陷——持久化已经写入，密钥可能已经外流，仅仅卸载包并不足以恢复。
排查与处置建议
对运维与安全团队，最优先的动作是用 pip show litellm 在全部运行 Agent 栈的机器上排查版本与安装时间。确认命中后，轮换云凭据、K8s 服务账号、SSH 密钥与 LLM API key，并审计 CI 中第三方 Action 的权限范围以及发布凭据的存放方式。
对开发者，需要在依赖管理中引入版本锁定与哈希校验；把网关类组件放进隔离环境，限制它对宿主凭据的可见性，避免一次 pip install 的窗口期直接兑换成整套基础设施的控制权。
对产业链而言，安全工具链自身（扫描器、CI Action、包仓库凭据）已经成为高价值攻击面。网关类基础设施项目需要把发布流程的完整性与运行时最小权限，当作与功能迭代同等级的产品能力来建设。
关键要点
- 攻击入口是 CI 中被攻陷的 Trivy GitHub Action，源码未被改动，代码审查挡不住这类攻击。
- 1.82.8 的
.pth机制让恶意代码在任何 Python 进程启动时执行，风险暴露面从“调用方”扩大到“整台机器”。 - 安装过 1.82.7 或 1.82.8 即视为失陷，处置重点是轮换凭据与检查主机，而非卸载重装。
- 网关是权限收敛点，应隔离部署并限制其对宿主凭据的可见性。