LiteLLM 官方网关突发 v1.107.0 供应链投毒事件：官方紧急回滚至 1.106.2 并发布深度复盘与凭证轮换指南

核心背景与行业痛点

在当今的大语言模型与智能体开发技术栈中，统一接口网关（Unified LLM Proxy）扮演着至关重要的流量枢纽角色。开源项目 LiteLLM 凭借提供与 OpenAI 规范兼容的单一统一接口，能够无缝桥接 Anthropic、Google、Bedrock、Azure 等上百种异构模型，月下载量突破数百万次，成为 LangChain、LlamaIndex、OpenHands 等几乎所有主流智能体开源项目的底层默认代理库。然而，正因为其处于所有大模型调用与 API 密钥的“咽喉要道”，此类工具一旦在构建阶段遭到供应链污染，黑客无需费力攻破目标企业的内网防火墙，即可直接利用开源依赖将恶意代码分发给数以万计的下游企业。北京时间 10 月 22 日，国际知名安全媒体 The Hacker News 与区块链安全机构慢雾（@SlowMist_Team）先后发出紧急安全预警，披露 LiteLLM 的官方分发链路遭遇了严重的恶意供应链投毒。

架构亮点与底层机制

1. CI/CD 发布流水线令牌失窃：

• 攻击者通过窃取或伪造合法维护者的自动化构建签名令牌，绕过了常规的代码合并 PR 审查；
• 在未经官方团队常规测试验证的情况下，直接触发了自动化打包脚本，向官方 PyPI 软件源与 Docker Hub 官方镜像仓库推送了恶意的 v1.107.0 构建产物；

1. 静默环境变量凭证窃取载荷（Credential Harvester）：

• 恶意代码被精巧地注入在 Python 包的底层初始化脚本中；
• 一旦开发者或生产容器执行 import litellm 或启动 Docker 容器，后门程序会立即遍历当前操作系统的全部环境变量，精确抓取包含 OPENAI_API_KEY、ANTHROPIC_API_KEY、AWS_SECRET_ACCESS_KEY 等敏感字段的字符串，并通过隐蔽的加密 DNS 请求或 HTTPS 隧道外发给攻击者受控的 C2 节点；

1. 波及范围与受影响镜像标签：

• 除了直接执行 pip install litellm 的生产环境外，使用 Docker 默认配置拉取 litellm:latest 或 litellm:main-stable 镜像标签的容器化服务首当其冲遭到感染。

权威 Benchmark 与实测跑分对比

• 事件响应与处置时效：
• 在恶意版本发布后数小时内，监控系统与白帽安全社区便捕获了异常外发流量；
• 官方团队迅速阻断了受污染的发布流水线凭证，并在全球 PyPI 仓库全面下架并撤回了 v1.107.0，将主包稳定版本强制回退至未受污染的 1.106.2；
• 排查建议与影响面：
• 安全厂商指出，凡是在污染时间窗口内自动更新过 LiteLLM 依赖或重新构建过 Docker 镜像的自动化集群，均存在凭据泄露风险，必须推定所有环境变量已被窃取；
• 全网关注度：
• 该事件在 X 平台与 Reddit 安全社区引发强烈震动，成为 2026 年度针对 AI Agent 基础设施的最具代表性现实攻击范本。

开发者实战落地与开箱指南

• 排查与版本固定（紧急行动）：
• 检查项目当前安装的 LiteLLM 版本：

    pip show litellm
    # 如果版本显示为 1.107.0，立即执行强行降级
    pip install "litellm==1.106.2" --force-reinstall
    

• Docker 部署修改：严禁在 docker-compose.yml 或 Kubernetes Deployment 中使用 :latest 或 :main-stable 动态标签，必须严格显式声明具体稳定哈希或版本号（如 ghcr.io/berriai/litellm:v1.106.2）；
• 核心凭据轮换操作：
• 所有配置在相关服务器上的大模型厂商 API Key（OpenAI、Anthropic、Gemini 等）、数据库连接密码与云平台访问凭证，必须立即登录厂商控制台执行作废（Revoke）并重新签发新密钥；
• 工程最佳实践：企业平台在 CI/CD 中应强制启用依赖锁文件（requirements.txt 带 hash 或 poetry.lock），并接入实时供应链安全审计工具，坚决杜绝自动拉取未经安全扫描的上游新版本。