从源码看漏洞:LiteLLM 9.3 分 SQL 注入背后的技术逻辑与防御指南

最近 AI 基础设施的安全圈真是“热闹”得让人睡不着觉。

作为当红的 AI Gateway 项目，LiteLLM 在 GitHub 上坐拥 4.5 万+ Star，是很多企业构建统一 AI 接口的首选。但就在最近，它爆出了一个 CVSS 评分高达 9.3 的超高危 SQL 注入漏洞（CVE-2026-42208）。

最让我感到背脊发凉的是，这个漏洞从正式披露到出现大规模利用，仅仅用了不到 36 小时。黑客甚至不需要等公开的 PoC（漏洞验证代码），直接对着源码就能实现“精准爆破”。

今天，我打算把这个漏洞拆开了、揉碎了跟大家聊聊，看看这 9.3 分到底是怎么得出来的，也帮大家避掉这些“低级却致命”的深坑。

1. 漏洞起因：那个熟悉又致命的“字符串拼接”

这次漏洞的核心逻辑其实非常“怀旧”——SQL 注入。在 2026 年的今天，看到这种级别的项目因为 SQL 注入翻车，确实挺让人唏嘘的。

根据 LiteLLM 维护者的官方通报，问题出在 Proxy API Key 的校验环节。为了验证调用者的身份，程序会去数据库里查询 Key 的合法性。然而，开发者在写那段查询逻辑时，没有使用安全的参数化查询，而是直接将用户传入的 Key 拼接到了 SQL 语句中。

“数据库查询在校验 API Key 时，直接将调用者提供的 Key 值混合到了查询文本中，而不是将其作为独立参数传递。”

更精妙（也更危险）的地方在于触发路径：攻击者不需要通过正常的身份验证。他们只需要构造一个特殊的 Authorization 头部，发送给任何一个 LLM API 路由（比如大家最常用的 POST /chat/completions），就能触发系统的错误处理路径。而那个存在注入风险的 SQL 查询，恰恰就藏在这一条路径里。

2. 36 小时沦陷：黑客是如何精准“点杀”的？

这次攻击者的响应速度快得离谱。GitHub 建议库在 4 月 19 日索引了该漏洞，而 4 月 26 日就监测到了第一次利用。攻击者表现出了极高的专业性：

• 针对性极强：
  
   攻击者直接瞄准了 litellm_credentials.credential_values 和 litellm_config 这两张表。
• 跳过冗余：
  
   他们完全没有碰 litellm_users 或 litellm_team 这种常规表。

这说明攻击者不仅对 LiteLLM 的源码了如指掌，甚至对它的 Prisma 数据库 Schema 做了深入研究。他们知道哪里存放着最值钱的东西——上游 LLM 供应商的 API Keys。

3. 爆炸半径：这不只是一个 Web 漏洞

为什么说这次漏洞的杀伤力接近于“云账户沦陷”？

因为 LiteLLM 作为网关，它的数据库里可能躺着：

• OpenAI 机构密钥：
  
   往往带有五位数的月消费限额。
• Anthropic 管理员权限密钥：
  
   涉及整个工作区的安全。
• AWS Bedrock IAM 凭据：
  
   甚至可能导致更广泛的云资源被盗。

一旦数据库被“掏空”，黑客拿到的不只是数据，而是一张张可以无限额消费的“信用卡”。

4. 防御指南：如何亡羊补牢？

如果你正在管理 LiteLLM 实例，请务必根据以下优先级进行操作：

1. 立即升级（最优解）

LiteLLM 已在 1.83.7-stable 版本中修复了此问题。请尽快检查你的容器镜像或 pip 版本。

2. 临时缓解措施

如果你因为业务原因无法立即重启升级，可以修改 general_settings 配置文件，强行切断注入路径：

general_settings:  disable_error_logs: true

通过禁用错误日志，可以移除未经身份验证的输入流向漏洞查询的必经之路。

3. 技术反思

作为技术人员，我们必须养成“安全肌肉记忆”：

• 严禁拼接：
  
   无论项目多急，永远不要在生产代码中使用字符串拼接构建 SQL。
• 最小权限：
  
   数据库连接账号应遵循最小权限原则，限制对敏感表的直接操作。
• 关注错误路径：
  
   很多高位漏洞都藏在非主流程的“异常处理”里，那里往往是防御最薄弱的地方。

写在最后

LiteLLM 的这次事件再次提醒我们，AI 基础设施的复杂性正在掩盖一些基础的安全隐患。36 小时的利用窗口期意味着，“以快打快”已经成了攻防的新常态。

希望各位老铁看完这篇能赶紧自查一下手头的服务，别让自己的服务器成了别人的“提款机”。

如果你觉得这篇文章有用，欢迎点赞、在看、分享给身边的技术小伙伴。安全无小事，咱们下期再见！

关键词：LiteLLM漏洞, CVE-2026-42208, SQL注入逻辑, AI Gateway安全, API Key泄露, 安全架构, 渗透测试