一夜之间人人自危：拆解 LiteLLM 投毒事件背后的供应链攻击路径-育师

一夜之间人人自危：拆解 LiteLLM 投毒事件背后的供应链攻击路径

【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100+ LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm

2026 年 3 月 24 日，一个足以让整个 AI 基础设施圈失眠的消息在安全社区炸开：支撑着成千上万家企业 AI 架构的开源 API 网关LiteLLM，被人在 PyPI 官方仓库投下了两个携带后门的版本。按 IT 之家的报道口径，LiteLLM 的月安装量约9500 万次，这意味着任何一次"顺手升级"，都可能把一家公司从 OpenAI、Anthropic 到 Azure 的全部模型调用凭证交到攻击者手里。本文基于公开报道与仓库源码，还原这次投毒事件的完整攻击路径，并从工程角度提炼可复用的防御范式。

一场教科书级的"官方通道发毒"

投毒事件最让人警觉的地方，恰恰是它没有使用常见的 typosquatting（仿冒包名）手法。攻击者没有注册一个拼写相似的litellmm或litellm-proxy来碰运气，而是直接通过 LiteLLM 自己的发布通道，在 PyPI 上发布了1.82.7 和 1.82.8两个带毒版本。对用户而言，这两个版本与上一个安全版本1.82.6只差两个 patch 号，pip install --upgrade litellm的常规升级路径毫无异常感——这正是供应链投毒最危险的地方：恶意载荷不来自陌生渠道，而来自你本就信任的官方版本号。

安全公司 Endor Labs 的溯源调查将攻击指向黑客组织TeamPCP。该组织在此之前已入侵过 Aqua Security 的 Trivy 扫描器，而 LiteLLM 自身的 CI/CD 流水线恰恰使用了这个已被入侵的 Trivy 工具，攻击者由此取得了 LiteLLM 的发布权限。也就是说，这是一条典型的"工具链→发布链"的纵深入侵：先污染开发者的安全扫描工具，再借该工具被信任的"安全背书"地位，攻破发布者的发布凭证，最终以官方身份向所有下游用户投毒。

藏在入口文件里的三阶段攻击负载

两个恶意版本在隐蔽性上做了分层设计，攻击手法一次比一次刁钻。

1.82.7：藏在必然被导入的文件里。恶意代码被植入proxy_server.py中——这正是本仓库中真正的入口文件（litellm/proxy/proxy_server.py），LiteLLM Proxy 启动时必然导入它。用户只要启动网关，恶意代码便随模块导入静默执行，无需任何额外交互。攻击者选择这个文件，本质上是精准命中了网关进程的"必经之路"。

1.82.8：利用.pth文件实现"零导入"感染。这是破坏力全面升级的一版。攻击者利用了 Python 的.pth配置文件特性：Python 解释器在启动时会自动处理site-packages目录下的.pth文件，其中以import开头的行会被当作代码执行。这意味着即使恶意包从未被任何业务代码显式import，只要环境中存在被投毒的litellm_init.pth，任何一次 Python 进程启动都会触发感染——从 SDK 脚本到 CI 任务，无一幸免。

配合两版载荷的，是一套完整的"三阶段"攻击链路：

凭据收集器：搜刮进程环境变量、配置文件与本地密钥环中的敏感凭据；
Kubernetes 横向移动工具：利用窃取到的集群凭证在 Pod 与节点之间渗透，扩大战果；
持久化后门：以伪装成"系统遥测服务"的形态落地，长期潜伏，规避常规巡检。

被窃取的数据范围触目惊心：SSH 密钥、AWS/GCP 云凭据、Kubernetes 机密、加密货币钱包、CI/CD 令牌——几乎覆盖了一台生产网关所能接触的全部"钥匙"。而 LiteLLM 恰恰就是那个掌握所有钥匙的节点：作为 API 网关，它一端握着各家模型提供商的 API Key，另一端握着企业的虚拟密钥、数据库连接串与云凭证。

数据回传：伪造域名与高强度加密的组合拳

为了让窃取的数据"偷得走、查不出"，攻击者在回传环节下了同样多的功夫。

域名伪装上，攻击者注册了极具误导性的models.litellm.cloud——与官方域名litellm.cloud高度相似，在安全日志里极易被误认为正常的遥测上报域名。流量隐匿上，所有外传数据在发送前都经过AES-256-CBC 与 RSA-4096的高强度加密，这让基于流量特征与内容匹配的检测手段基本失效——安全团队即使抓包，看到的也只是一堆无法解密的密文。

值得指出的是，LiteLLM 自身在密钥保护上其实并不薄弱：仓库中的存储凭据加密实现（litellm/proxy/common_utils/encrypt_decrypt_utils.py）同时支持 AES-256-GCM（v2:gcm:前缀）与 XSalsa20-Poly1305 两种算法，并可通过LITELLM_SALT_KEY将加密密钥与主密钥分离。但这一切都建立在代码本身可信的前提下——一旦发布通道被攻破，再强的"静态加密"也防不住"运行时代码"本身在偷数据。攻击者选择回传前加密，正是为了绕开对"敏感数据出网"的明文检测，让你连该封哪个域名都无从下手。

AI 基建：为什么它是攻击者的"高价值靶标"

这场攻击的选址绝非偶然。LiteLLM 这类 LLM 网关处在 AI 基础设施的价值链正中心，具有三个让攻击者垂涎的属性：

第一，它是密钥的"汇聚点"。网关天然需要聚合所有上游模型提供商的 API Key、下游用户的虚拟密钥与预算配额，一个网关上可能同时存在几十上百条凭据。攻破一个节点，等于拿到整个组织的模型调用权限和账单控制权。

第二，它是流量的"必经之地"。所有 AI 请求、所有 prompt 与所有响应都流经网关。攻击者不仅能偷密钥，理论上还能在 prompt 层面对业务数据下手——这对把核心提示词和私有数据交给 AI 应用的企业是灾难性的。

第三，它是 CI/CD 的"信任锚"。正如本次事件所示，攻击者先污染 Trivy 扫描器，再借 LiteLLM 对安全工具的无条件信任攻入发布链。工具链信任是供应链中最脆弱的环节：安全检查工具本身不被检查，成为整个链条上最大的暗门。

这起事件与同期安全界热议的"AI 蠕虫""AI 基建成攻击温床"等话题互为印证——攻击者正在系统性地把 AI 基础设施当作循环攻击的温床：攻破网关→窃取云凭证→横向移动→再用窃取的算力与模型权限发起下一轮攻击。

从这次事件提炼可复用的防御范式

复盘事件之后，真正有价值的是把"事后应急"转化为"事前防御"。以下范式既有本次事件的经验，也能在本仓库的真实工程实践中找到对应实现。

范式一：把"发布物"当作第一道防线，版本与文件双向核验。

立即执行pip show litellm | grep Version确认版本，并检查site-packages下是否存在litellm_init.pth；
若曾安装 1.82.7/1.82.8，必须强制轮换所有云密钥、SSH 私钥、数据库密码与 K8s 令牌——密钥一旦外泄，任何"删除恶意包"的操作都无法挽回；
将版本固定到安全版本 1.82.6，并安全审计过去 48 小时内运行过的所有 CI/CD 流水线，排查残留后门。

范式二：让启动期"强制安全校验"成为默认。本仓库在启动链路中内置了硬性门槛：litellm/proxy/auth/master_key_boot_check.py 会在 Proxy 启动时执行主密钥判定——未设置master_key、密钥为空、或密钥是公开已知的默认值（通过内置的 SHA-256 摘要黑名单比对）时，直接拒绝启动并打印修复指引，而不是带着裸奔配置继续跑。这种"宁可拒绝服务，不可无鉴权上线"的启动自检，正是应对"环境被静默污染"场景的关键防御：让异常环境在第一时间暴露，而不是带病运行。

范式三：密钥管理要"分层、分离、外部化"。把敏感配置从代码与进程环境中剥离：本仓库的加密实现通过LITELLM_SALT_KEY与master_key分离加密密钥（encrypt_decrypt_utils.py 中get_salt_key()的优先级设计），同时提供了完整的 Secret Manager 接入层（litellm/secret_managers/），支持 AWS Secrets Manager、Google KMS、HashiCorp Vault、CyberArk 等外部托管。生产环境中应让密钥存于 KMS/HSM，运行时只取用不落盘——这样即便网关进程被入侵，攻击者也拿不到可用于解密的长期密钥。

范式四：把安全工具本身纳入供应链信任边界。本次事件的根源是"被入侵的扫描器获得了发布权限"。防御上要做到：

工具溯源校验：本仓库的 OSV 扫描工作流（.github/workflows/osv-scan.yml）下载 osv-scanner 后先做 SHA-256 校验再执行；Dockerfile 中所有基础镜像与第三方构建产物（如 pgbouncer）均 pin 到精确的 digest 并校验校验和——用"哈希锁定"斩断工具链被替换的路径；
依赖变更隔离：.github/workflows/guard-fork-dependencies.yml 专门阻止来自 fork 的 PR 改动uv.lock与pyproject.toml——依赖锁文件的变更被视为高敏感变更，防止恶意依赖在代码评审的盲区混入；
持续供应链评分：scorecard.yml（OSSF Scorecard）、codeql.yml、image-scan.yml与多套 Trivy/Grype 容器扫描（见 ci_cd/security_scans_readme.md）共同构成多层防线。

范式五：默认假设"网关已失陷"，做横向移动的对冲。本次攻击的三阶段中，K8s 横向移动是关键扩大面。防御侧应对称地做到：网关进程以最小权限运行（K8s RBAC 只读、无create权限）、虚拟密钥按团队/用户最小化分配、出网流量仅白名单放行并监控异常加密外传、数据库与云凭据启用临时凭证（如 OIDC/工作负载身份）而非长期静态密钥。

结语

LiteLLM 投毒事件最值得警醒的一点，是它把"供应链攻击"从抽象的威胁模型变成了真实的杀伤路径：攻击者没有攻破代码，而是攻破了"发布代码的人所信任的工具"。当安全扫描器本身可以被污染、官方版本号可以被冒用时，任何单一防御点都不再值得无条件信任。对企业而言，这次事件是一次强制体检：你的依赖锁文件有没有被哈希锁定？你的安全工具有没有被纳入信任边界？你的网关密钥有没有实现分离与外部化？一夜之间人人自危的代价，应该换来的是一个再也无法被同一手法攻破的供应链。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考