一夜之间人人自危拆解 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/litellm2026 年 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.pyLiteLLM 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-GCMv2: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.ymlOSSF Scorecard、codeql.yml、image-scan.yml与多套 Trivy/Grype 容器扫描见 ci_cd/security_scans_readme.md共同构成多层防线。范式五默认假设网关已失陷做横向移动的对冲。本次攻击的三阶段中K8s 横向移动是关键扩大面。防御侧应对称地做到网关进程以最小权限运行K8s RBAC 只读、无create权限、虚拟密钥按团队/用户最小化分配、出网流量仅白名单放行并监控异常加密外传、数据库与云凭据启用临时凭证如 OIDC/工作负载身份而非长期静态密钥。结语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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考