首页 / 新闻动态 / AI大模型网关LiteLLM爆出严重漏洞CVE-2026-4...

AI大模型网关LiteLLM爆出严重漏洞CVE-2026-42208：预认证SQL注入可窃取所有AI密钥

📅 2026-05-10 10:16:21 | 👁️ 阅读 1 | 📂 新闻动态

漏洞背景：AI网关成为攻击新靶点

2026年4月下旬，在AI开发领域被广泛使用的大模型统一接入网关LiteLLM被披露存在一个严重安全漏洞，编号为CVE-2026-42208。该漏洞CVSS评分高达9.3（严重级别），攻击者无需任何认证即可通过构造恶意的Authorization请求头，在后端PostgreSQL数据库中执行任意SQL语句。

LiteLLM的核心定位是作为统一AI网关，为开发者提供与超过100个大语言模型提供商的兼容接口。企业通常通过LiteLLM集中管理OpenAI、Anthropic、AWS Bedrock、Google Gemini等平台的API密钥。一旦网关被攻破，攻击者可以一次性窃取所有配置的AI提供商密钥——这意味着单次漏洞利用可能导致组织在多个AI平台上的凭据同时泄露。

CVE-2026-42208 技术详情

漏洞由BerriAI通过其Bug Bounty计划接收报告，随后通过负责任的披露流程发布了修复版本。

项目详情
披露时间2026年4月29日（公开披露）
受影响版本LiteLLM Proxy v1.81.16 ~ v1.83.6
修复版本v1.83.7（2026年4月18日发布）
CVSS评分9.3（严重/Critical）
攻击向量预认证SQL注入（Authorization: Bearer头）
在野利用是，公开披露后约36小时出现

漏洞原理：f-string SQL注入的经典案例

漏洞位于litellm/proxy/utils.py中的PrismaClient.get_data()函数。开发人员使用Python f-string直接将用户输入（token变量）拼接到SQL查询语句中，而非使用参数化查询：

# 漏洞代码（f-string 插值，未使用参数化查询）
sql_query = f"""
  SELECT v.*, t.spend AS team_spend
  FROM "LiteLLM_VerificationToken" AS v 
  LEFT JOIN "LiteLLM_TeamTable" AS t ON v.team_id = t.team_id
  WHERE v.token = '{token}'
"""

攻击者只需在Authorization: Bearer请求头中构造包含SQL注入payload的字符串（不以sk-开头即可绕过哈希处理），即可将任意SQL语句注入到数据库查询中。

两条攻击路径：为什么漏洞如此容易触发

Bishop Fox研究人员发现了两条可以到达漏洞代码执行路径：

Path A：assert语句被优化掉

LiteLLM的认证流程依赖assert api_key.startswith("sk-")来验证Bearer令牌格式。然而当Python以-O优化模式或PYTHONOPTIMIZE=1运行时，assert语句会被完全移除。一些加固过的容器镜像会应用此优化，导致认证检查被绕过。

Path B：异常处理流泄漏原始token（默认情况）

在默认配置下，assert会触发AssertionError，但异常被外层except捕获并进入错误处理流程。在错误回调链中，原始Bearer令牌被填入元数据，最终传递到辅助函数，进而调用查询函数。变量名api_key_hash强烈暗示是哈希值，实际上持有的是原始攻击者控制的字符串——这种命名误导是漏洞持续存在的原因之一。

基于时间的盲注利用

由于漏洞点位于认证流程中，HTTP响应对所有探测均返回相同的401错误。攻击者无法使用错误型注入或UNION注入，唯一的利用信道是基于时间的盲注（Time-Based Blind SQL Injection）。

攻击者可以构造如下Authorization头：

Authorization: Bearer ' OR (SELECT pg_sleep(6)) IS NULL --

通过测量HTTP响应的时间延迟，攻击者可以逐位提取数据库中的任意数据。若目标存在漏洞，响应时间约为6秒；若已修复，响应时间小于100毫秒。

实际危害：一次性窃取所有AI提供商密钥

LiteLLM作为集中式AI网关，所有提供商的API密钥都存储在后端的PostgreSQL数据库中。通过SQL注入漏洞，攻击者可以：

  • 完整读取验证令牌表，获取所有虚拟密钥及其关联的提供商密钥（OpenAI、Anthropic、AWS Bedrock、Google Gemini等）
  • 数据库超级用户权限：在默认Docker部署中，应用数据库用户通常是超级用户
  • 进一步升级为RCE：研究人员演示了在LiteLLM容器内实现完整远程代码执行的利用链

对于重度依赖AI能力的企业而言，这是一场灾难性的安全事件——单次漏洞利用即可导致组织在所有AI平台上的凭据同时泄露。

在野利用时间线

日期事件
2026年4月18日v1.83.7-stable标签发布（修复版本）
2026年4月25日GitHub Security Advisory公开发布
2026年4月27日观测到首次在野利用尝试（公告后约36小时）

这一时间线再次印证了漏洞公开披露后，在野利用时间窗口正在急剧缩短的趋势。

修复方案

  1. 立即升级：将LiteLLM Proxy升级至v1.83.7或更高版本（推荐v1.83.10-stable）
  2. 临时缓解措施：在WAF中设置规则拒绝所有不匹配^sk-[A-Za-z0-9_-]+$的Authorization: Bearer值
  3. 密钥轮换：升级后必须轮换在漏洞窗口期内活跃的所有虚拟密钥和提供商API密钥
  4. 日志审计：审计PostgreSQL查询日志，查找异常的数据库查询模式

对AI基础设施安全的深度思考

第一，基础漏洞类型仍在2026年出现。f-string SQL注入是最基本的安全编码错误之一，说明安全编码培训覆盖仍不彻底。

第二，AI基础设施正成为攻击者的高价值目标。AI网关集中管理多个提供商的凭据，形成了"单点失败"的高风险架构。企业在采用AI工具链时，必须重新审视这类组件的安全姿态。

第三，AI驱动的安全工具正在改变攻防节奏。Anthropic的Mythos模型已经能够自动发现大量历史漏洞，漏洞披露速度正在加快。防守方需要建立更敏捷的漏洞响应机制。

结语

随着AI在企业中的广泛部署，AI基础设施的安全性将越来越受到关注。CVE-2026-42208提醒我们，在追求AI能力的同时，不能忽视基础的安全编码规范和基础设施防护。

参考：Bishop Fox、LiteLLM官方公告、Cloud Security Alliance

💬 评论 (0)