LiteLLM 爆高危 SQL 注入：无需凭证可读取所有 API 密钥

行业快讯

月下载量 9500 万次的 AI 统一接口库 LiteLLM 被曝存在 SQL 注入漏洞（CVE-2026-42208），攻击者无需任何凭证即可通过构造 Bearer token 读取数据库中所有模型 API 密钥，公网暴露实例风险极高。

LiteLLM 爆高危 SQL 注入：无需凭证可读取所有 API 密钥

月下载量 9500 万次的 AI 统一接口库 LiteLLM 今天被曝存在高危 SQL 注入漏洞（CVE-2026-42208）。攻击者无需任何有效凭证，只需构造特定的 Bearer token，就能在认证失败的错误日志中注入 payload，从而未授权读取数据库内保存的所有模型 API 密钥——包括 OpenAI、Anthropic、Google、AWS 等各大厂商的密钥。

这个漏洞影响版本范围是 >= 1.81.16 且 < 1.83.7，官方已在 v1.83.7-stable 中修复。但考虑到 LiteLLM 在 AI 工程师群体中的渗透率，以及它作为「密钥中转站」的特殊定位，这次漏洞的实际影响面可能远超想象。

漏洞细节：认证失败日志成了攻击入口

LiteLLM 的 Proxy 组件在处理 API 请求时，会先验证 Bearer token 的有效性。如果 token 无效，系统会记录一条错误日志，内容包含这个无效的 token 字符串。问题就出在这里：错误日志的生成过程中，token 字符串被直接拼接进了 SQL 查询语句，没有做任何转义或参数化处理。

攻击者只需要在 HTTP 请求的 Authorization 头中构造一个包含 SQL 注入 payload 的 Bearer token，比如：

Authorization: Bearer sk-xxx' UNION SELECT api_key FROM litellm_verificationtoken--

当 LiteLLM 尝试验证这个 token 并记录认证失败日志时，恶意 SQL 语句就会被执行。由于错误日志通常会返回给客户端（或者至少会被记录到可访问的日志文件中），攻击者可以直接从响应或日志中读取查询结果——也就是数据库里存储的所有 API 密钥。

整个攻击过程不需要任何有效凭证，不需要通过认证，甚至不需要知道数据库结构（因为 LiteLLM 的表结构是开源的）。只要你的 LiteLLM Proxy 实例暴露在公网上，任何人都可以尝试这个攻击。

为什么这个漏洞特别危险

如果这是一个普通的 Web 应用，SQL 注入漏洞虽然严重，但影响范围通常局限在应用本身的数据。LiteLLM 不一样，它的核心功能就是作为多个模型提供商的统一代理层，这意味着：

  1. 密钥集中度高：一个 LiteLLM 实例里可能存着十几个甚至几十个不同提供商的 API 密钥。攻击者拿到的不是某一个 key，而是一整套跨提供商的凭证集合。

  2. 横向影响大：这些密钥通常都绑定了付费账户，攻击者可以直接消耗受害者的配额，或者用这些密钥发起更大规模的攻击（比如用 GPT-4 的 key 去做大规模数据抓取）。

  3. 检测难度高：因为攻击发生在认证失败阶段，不会触发正常的业务日志。如果管理员没有专门监控错误日志中的异常 SQL 语句，很可能完全察觉不到被攻击了。

  4. 公网暴露率高：很多团队会把 LiteLLM Proxy 部署成公网可访问的服务，方便内部多个项目调用。这种部署方式在这次漏洞面前几乎是裸奔。

微步在线的情报显示，这个漏洞在 4 月 28 日被收录后，已经有攻击者开始在公网上扫描暴露的 LiteLLM 实例并尝试利用。Sysdig 的报告更指出，漏洞披露后 36 小时内就观察到了针对性的攻击流量。

这不是 LiteLLM 第一次出事

如果你关注 AI 开源生态的供应链安全，应该对 LiteLLM 这个名字不陌生。就在一个月前（3 月 24 日），LiteLLM 刚刚经历了一次更严重的供应链投毒事件。

当时的攻击链是这样的：

  • 3 月 19 日：开源漏洞扫描器 Trivy 被黑客劫持
  • 3 月 23 日：黑客攻陷 Checkmarx KICS
  • 3 月 24 日：黑客利用被污染的 Trivy 从 LiteLLM 的 CI/CD 管道中窃取 PyPI token，然后发布了两个带毒版本（1.82.7 和 1.82.8）

这两个恶意版本的代码会：

  • 遍历系统中的 SSH 密钥、.env 文件、云凭证、k8s 配置、Git 凭证等所有敏感数据
  • 用 RSA-4096 + AES-256-CBC 加密后上传到黑客服务器
  • 如果检测到 k8s 服务账户令牌，还会利用令牌安装后门实现横向传播

更狠的是，1.82.8 版本在安装时会往 site-packages 目录里放一个 .pth 文件。Python 解释器启动时会自动执行 .pth 文件中以 import 开头的行，这意味着只要这个版本被安装进某个 Python 环境，该环境里启动的任何 Python 进程都会执行恶意代码——不管你跑的是 Flask、Jupyter、pytest 还是完全不相关的脚本，也不需要你 import LiteLLM。

恶意版本上线时间约 3 小时，按 LiteLLM 日均 340 万次下载计算，保守估计有 42 万个实例安装了带毒版本。泄露的数据量无法估计，但可以确定的是，大量 k8s 集群被攻陷，海量 API 密钥和云凭证被窃取。

值得注意的是，黑客编写的恶意代码里存在一个循环执行的 BUG，导致服务器资源耗尽。如果不是这个 BUG 暴露了异常，可能根本没人发现 LiteLLM 被投毒。有安全研究人员推测，这个 BUG 很可能是因为黑客用 AI 生成恶意代码时没有充分测试。

为什么 LiteLLM 成了重灾区

LiteLLM 在 AI 工程师群体中的地位有点像前端开发里的 Axios 或后端开发里的 Requests——不是最核心的框架，但几乎每个项目都会用到。它的核心价值是抹平不同模型提供商的 API 差异，让你用统一的接口调用 GPT、Claude、Gemini、DeepSeek 等几百个模型。

这种定位带来了两个问题：

  1. 依赖广度大：DSPy、CrewAI、LangChain 等大量 AI 框架都把 LiteLLM 列为依赖。一旦 LiteLLM 出问题，整个下游生态都会受影响。

  2. 密钥集中度高：因为 LiteLLM 要对接多个提供商，开发者必须把所有 API 密钥配置在本地环境变量或服务器上。这些密钥通常都是高权限的生产密钥，而不是测试用的受限 key。

再加上 LiteLLM 的部署模式——很多团队会把它部署成一个中心化的 Proxy 服务，供内部多个项目调用——这就让它成了一个天然的「密钥金库」。攻击者只要攻陷一个 LiteLLM 实例，就能拿到一整套跨项目、跨提供商的密钥。

从攻击者的角度看，LiteLLM 是一个投入产出比极高的目标：

  • 部署量大（月下载 9500 万次）
  • 密钥价值高（生产环境的付费 API key）
  • 攻击成本低（开源代码，攻击面清晰）
  • 检测难度高（很多团队没有专门的供应链安全监控）

你现在需要做什么

如果你在用 LiteLLM，不管是直接用还是通过其他框架间接依赖，都需要立即检查：

1. 确认版本

pip show litellm

如果版本在 1.81.16 到 1.83.6 之间，你的实例存在 SQL 注入漏洞。如果版本是 1.82.7 或 1.82.8，你还需要按供应链投毒事件处理。

2. 升级到安全版本

pip install --upgrade litellm==1.83.7

或者在 requirements.txt / pyproject.toml 中锁定版本：

litellm==1.83.7

3. 轮换所有 API 密钥

这一步是必须的，即使你的实例没有暴露在公网上。因为你无法确定在漏洞修复之前，是否有人已经利用过这个漏洞。

需要轮换的密钥包括但不限于：

  • OpenAI API key
  • Anthropic API key
  • Google AI API key
  • AWS Bedrock credentials
  • Azure OpenAI credentials
  • 所有其他在 LiteLLM 配置中出现过的密钥

4. 检查日志

如果你的 LiteLLM 实例有完整的访问日志，搜索是否有包含 SQL 关键字（如 UNION、SELECT、--）的异常 Bearer token。如果有，说明可能已经被攻击过。

5. 临时缓解措施

如果你暂时无法升级，可以在配置文件中设置：

general_settings:
  disable_error_logs: true

这会关闭错误日志，从而阻断攻击路径。但这只是临时方案，不能替代升级和密钥轮换。

更大的问题：AI 开源生态的供应链脆弱性

LiteLLM 连续两次出事，暴露的不只是一个项目的安全问题，而是整个 AI 开源生态在供应链安全上的系统性脆弱。

依赖锁定缺失

AI 领域迭代快，框架更新频繁，很多开发者习惯用宽松版本约束甚至直接 pip install 不指定版本。这在供应链攻击面前几乎是自杀行为。

3 月的投毒事件中，很多受害者是因为 CI/CD 流水线或 Docker 构建脚本里写的是 pip install litellm，没有锁定版本，导致自动拉取了恶意版本。

如果你在用 uv，uv.lock 默认已经做了锁定。如果用 poetry 或 pip-tools，确保 CI/CD 和 Docker 构建只从 lock file 安装。

密钥管理混乱

很多 AI 项目的密钥管理方式还停留在「把 API key 写在 .env 文件里」的阶段。这种方式在本地开发时问题不大,但一旦部署到生产环境，或者代码被提交到 Git 仓库（即使是私有仓库），风险就会急剧上升。

更好的做法是：

  • 生产环境用 AWS Secrets Manager、HashiCorp Vault 等专业密钥管理服务
  • 为不同环境（开发/测试/生产）使用不同的 API key
  • 定期轮换密钥，不要一个 key 用到天荒地老
  • 给 API key 设置使用限制（如速率限制、IP 白名单）

上游依赖的信任链

3 月的投毒事件中，攻击链的起点是 Trivy——一个被广泛使用的开源漏洞扫描器。很多项目的 CI/CD 流水线里都集成了 Trivy 做安全扫描，但没人想到 Trivy 本身会被攻陷。

这暴露了一个更深层的问题：我们对上游依赖的信任是盲目的。你可能会仔细审查自己项目的代码，但你会去审查 Trivy、pytest、pip 这些工具的代码吗？不会。因为审查成本太高，而且这些工具的更新频率很快，你根本审查不过来。

但攻击者恰恰利用了这一点。他们不会直接攻击你的项目，而是攻击你依赖的工具链。一旦工具链被污染，所有使用这个工具的项目都会中招。

对 AI API 聚合平台的启示

LiteLLM 的问题也给 AI API 聚合平台（包括 OpenAI Hub 这类服务）提了个醒：密钥管理是核心安全边界。

聚合平台的商业模式决定了它必须持有大量用户的 API 密钥，这让它成为攻击者的高价值目标。一旦平台被攻破，泄露的不是某一个用户的密钥，而是所有用户的密钥。

从架构设计上，聚合平台需要考虑：

  1. 密钥加密存储：数据库里的密钥必须加密存储，密钥本身不能以明文形式出现在任何日志、错误信息或调试输出中。

  2. 最小权限原则：应用层代码不应该有直接读取密钥表的权限。密钥的读取应该通过专门的密钥管理服务，并且有严格的访问控制和审计日志。

  3. 异常检测：监控 API 调用模式，如果某个密钥突然出现异常的调用量或调用来源，应该立即告警。

  4. 定期安全审计：不只是代码审计，还要审计依赖链、CI/CD 流水线、部署配置等所有可能成为攻击面的环节。

LiteLLM 的 SQL 注入漏洞本质上是一个低级错误——没有对用户输入做参数化处理。但这个低级错误在一个持有大量高价值密钥的系统里，造成的影响是灾难性的。这也提醒所有做 AI 基础设施的团队：在密钥管理这件事上,没有小问题。

写在最后

LiteLLM 一个月内连续出两次重大安全事件，已经不是运气不好能解释的了。这反映了项目在安全开发流程上的系统性缺失：

  • SQL 注入这种 OWASP Top 10 级别的漏洞，应该在代码审查阶段就被发现
  • PyPI token 不应该直接存在 CI/CD 流水线的环境变量里，应该用更安全的密钥管理方案
  • 依赖的安全性（如 Trivy）应该有独立的验证机制，不能盲目信任

对于使用 LiteLLM 的开发者来说，现在需要做的不只是升级版本和轮换密钥，还要重新审视自己的依赖管理和密钥管理策略。AI 开源生态的供应链攻击只会越来越多，我们需要做好长期应对的准备。

如果你在用 OpenAI Hub 这类聚合平台，至少可以把密钥管理的责任转移给平台方——当然前提是平台本身的安全性足够可靠。但如果你选择自建 LiteLLM 这类方案，就必须自己承担相应的安全责任。这次事件已经证明，这个责任比很多人想象的要重得多。

参考来源