登录
漏洞分析

🎯 CVE-2026-42208 深度技术分析：漏洞根因 · PoC/EXP · 检测指纹

AiRedTeam

• 阅读时间 9 分钟
分享
🎯 CVE 全聚合深度分析

CVE-2026-42208 深度技术分析

📊 聚合 3 来源🧪 含 PoC🕵️ 含指纹
NVD-LatestCISA-KEVPoC-in-GitHub

摘要：CVE-2026-42208 是 BerriAI LiteLLM 代理服务器（AI Gateway）中一处严重的 SQL 注入漏洞，CVSS 评分为 9.8。该漏洞源于 LiteLLM 在代理 API Key 校验过程中，将攻击者可控的输入直接拼接到数据库查询文本中，而非使用参数化查询。未认证攻击者可向任意 LLM API 路由（如 POST /chat/completions）发送特制的 Authorization 头，在触发代理错误处理路径时到达脆弱查询，进而读取甚至修改 LiteLLM 代理数据库中的敏感数据，最终可能导致代理及其所管理的 LLM API 凭据被未授权访问。该漏洞已在 LiteLLM 1.83.7 版本修复，且已被 CISA KEV 收录，表明已存在在野利用或积极利用迹象。

📌 漏洞概述

  • CVE 编号：CVE-2026-42208
  • CVSS 评分：9.8（Critical）
  • 漏洞类型：SQL 注入（CWE-89）
  • 受影响版本：LiteLLM ≥ 1.81.16 且 < 1.83.7
  • 修复版本：LiteLLM 1.83.7
  • 利用前置条件：无需认证，攻击者只需能访问 LiteLLM 代理暴露的 HTTP 端点
  • CISA KEV 状态：已收录，具备在野利用证据，需按 BOD 22-01 要求优先处置

LiteLLM 是一款广泛使用的开源 AI 网关/代理，用于将 OpenAI 格式的请求转发至各类 LLM 后端，并统一管理 API 密钥、配额和路由。由于其在企业 AI 基础设施中常作为凭据与流量的集中入口，该漏洞一旦被利用，可能造成严重的横向渗透与数据泄漏。

🔬 漏洞根因分析

该漏洞的根本原因在于 LiteLLM 在处理代理 API Key 校验时，使用了不安全的数据库查询构造方式。根据官方通告，从版本 1.81.16 到 1.83.7 之前，LiteLLM 的某个用于代理 API Key 校验的数据库查询，将调用者提供的 Key 值直接拼接到 SQL 查询文本中，而不是作为绑定参数传入。这种经典的字符串拼接方式意味着攻击者可以通过注入 SQL 语法来改变查询语义。

值得注意的是，该查询并非暴露在常规的功能路径中，而是位于代理的错误处理路径（error-handling path）。在正常请求中，LiteLLM 会先解析 Authorization 头中的 Bearer Key，随后在数据库中查找该 Key 对应的配置、配额、权限等信息。当攻击者发送一个格式极不规则或包含特殊字符的 Authorization 头时，LiteLLM 的认证逻辑可能进入异常分支，而该分支中的降级查询（fallback query）恰好存在 SQL 注入。PoC 扫描器（如 litellm-sqli-scanner）正是利用了这一特性：通过向目标发送带有恶意构造的 Authorization 头的 POST /chat/completions 请求，并观察响应中的错误信息或时间延迟，来判断目标是否存在注入点。

由于注入发生在数据库查询中，且 LiteLLM 使用的数据库多为 PostgreSQL、MySQL 或 SQLite（取决于部署配置），攻击者可以利用 SQL 语法进行 UNION 查询、报错注入、布尔盲注或时间盲注。例如，使用 Authorization: Bearer ' UNION SELECT ... 或 ' OR '1'='1 等载荷，即可绕过原本的 Key 校验逻辑，或者从数据库中提取管理员凭据、LLM API Key、用户列表等敏感信息。更严重的是，若数据库用户权限较高（如 LiteLLM 安装时的默认数据库账户），攻击者还可能通过堆叠查询（stacked queries）执行 UPDATE、INSERT 甚至 DELETE 语句，从而篡改代理配置、添加恶意用户或直接获取所有后端 LLM 的访问凭据。

该漏洞与常见的 ORM 注入不同，它并非因为 ORM 使用不当，而是开发者在特定查询中采用了原始 SQL 字符串拼接，并遗漏了参数化检查。由于错误处理路径在正常测试中不易被覆盖，此类问题往往能绕过常规安全扫描和代码审计，仅在特定异常输入下触发，因此具有较高的隐蔽性。

💥 影响与危害

  • 未认证数据泄露：攻击者无需任何有效凭据即可读取 LiteLLM 数据库中的全部数据，包括代理用户账号、API Key 哈希、后端 LLM 提供商的明文或可解密凭据、调用日志与计费信息。
  • 凭据接管与横向移动：通过获取数据库中的 OpenAI、Anthropic、Azure OpenAI 等服务的 API Key，攻击者可直接以企业身份调用大模型服务，造成巨额账单，或利用凭据访问其他关联系统。
  • 代理配置篡改：利用堆叠注入修改数据库记录，攻击者可创建自己的代理 Key、提升权限、禁用安全校验或将流量转发至恶意服务器，实现对代理流量的完全控制。
  • 供应链与内部网络风险：LiteLLM 通常部署在企业内网并连接多个内部服务和数据库，SQL 注入可能成为进一步渗透内网的跳板，结合其他漏洞可能导致严重的数据安全事故。
  • 在野利用风险：CISA KEV 已收录该漏洞，表明攻击者已开始针对暴露的 LiteLLM 实例进行扫描和利用。由于 CVSS 9.8 且无需认证，任何暴露在公网的 LiteLLM 代理都处于高度危险之中。

🛡️ 修复与缓解

官方补丁：立即升级至 LiteLLM 1.83.7 或更高版本。该版本修复了数据库查询中参数拼接问题，改用安全的参数化查询或预编译语句，确保用户输入仅作为数据处理而非执行代码。

临时缓解措施：

  • 限制网络暴露：勿将 LiteLLM 代理直接暴露在公网。应通过内网 VPN、跳板机或反向代理（如 Nginx）限制访问来源 IP。
  • 部署 WAF/API 网关：在代理前部署 Web 应用防火墙，对 Authorization 头中的异常字符（如单引号、SQL 关键字）进行过滤或阻断，降低注入尝试成功率。
  • 最小化数据库权限：为 LiteLLM 使用的数据库账户分配最小必要权限，禁止 DDL/DML 高风险操作，并设置独立账号以隔离其他业务库。
  • 监控与审计：启用数据库慢查询日志和错误日志，关注来自异常来源的多次认证失败或含特殊字符的 Authorization 头；部署 SQL 注入检测规则，对类似 ' UNION、' OR 等模式进行实时告警。
  • 凭据轮换：若怀疑已受影响，立即轮换所有存储于 LiteLLM 中的后端 LLM API Key 以及代理自身的数据库凭据，并审查日志确认是否存在未授权访问。
  • 跟踪 CISA 指导：遵循 BOD 22-01 要求，对于无法立即修复的云服务实例，评估是否暂停使用直至补丁应用；若短期内无法升级，考虑关闭代理服务或仅允许受信任的内网访问。

🧪 PoC 复现

从 GitHub 公开仓库抓取的实际 PoC 代码（仓库）。

📋 代码元数据语言md来源ridhinva/litellm-sqli-scanner针对性✅ 已验证与漏洞相关（代码含 CVE 引用）依赖见代码注释/README用法详见代码注释中的使用说明

# LiteLLM SQL Injection Scanner

>
CVE-2026-42208 — SQL injection in LiteLLM Proxy

Detects and validates CVE-2026-42208: SQL injection vulnerability in LiteLLM Proxy's database layer.
For authorized security testing only.

## Features

- CVE-2026-42208 SQL injection detection
- LiteLLM Proxy version fingerprinting
- PoC validation payloads
- Structured JSON / text output

## Requirements

- Python 3.8+

## Usage

```bash
python litellm_scanner.py --url http://target:4000      # Scan a target
python litellm_scanner.py --url http://target:4000 --poc # Run PoC validation
python litellm_scanner.py --help                         # Help
```

## Legal

**For authorized testing only.** Only scan systems you own or have explicit written permission to test.

## Author

ridhinva — https://github.com/ridhinva

⚔️ EXP 利用代码

截至分析时，Exploit-DB 未收录该 CVE 的公开利用代码。可利用上述 PoC 进行验证，或关注 Exploit-DB 更新。

🕵️ 检测指纹

针对该 CVE 的自动化检测规则（可直接用于扫描与审计）。

🛡️ Semgrep 审计规则: CVE-2026-42208.yaml

📋 代码元数据语言yaml来源rules/semgrep/CVE-2026-42208.yaml针对性✅ 按 CVE 匹配依赖semgrep用法semgrep --config CVE-2026-42208.yaml

rules:
  - id: CVE-2026-42208-sqli-python
    languages:
      - python
    severity: ERROR
    message: "Potential SQL injection in LiteLLM proxy API key check via string formatting instead of parameterized query"
    patterns:
      - pattern-either:
          - pattern: |f"SELECT * FROM $TABLE WHERE key = $VALUE"
    pattern-not: |f"SELECT * FROM $TABLE WHERE key = ?"
    fix: |
cursor.execute("SELECT * FROM proxy_keys WHERE key = ?",
(key_value,))
    metadata:
      cwe: "CWE-89"
      owasp: "A1: Injection"
      technology: litellm
      references:
        - "https://nvd.nist.gov/vuln/detail/CVE-2026-42208"
  - id: CVE-2026-42208-sqli-python-format
    languages:
      - python
    severity: ERROR
    message: "Potential SQL injection via string formatting in database query"
    patterns:
      - pattern-either:
          - pattern: $QUERY.format(key=$VALUE)
      - pattern-not: $QUERY.format(key="?")
    fix: |
cursor.execute("SELECT * FROM proxy_keys WHERE key = ?",(key_value,))
    metadata:
      cwe: "CWE-89"
      owasp: "A1: Injection"
      technology: litellm
      references:
        - "https://nvd.nist.gov/vuln/detail/CVE-2026-42208"

🛡️ CodeQL 审计规则: CVE-2026-42208.ql

📋 代码元数据语言ql来源rules/codeql/CVE-2026-42208.ql针对性✅ 按 CVE 匹配依赖codeql用法codeql database run

/**
 * @kind path-problem
 * @id python/sql-injection/cve-2026-42208
 * @name SQL injection in LiteLLM proxy database query
 * @description User-controlled Authorization header value is concatenated into a database query instead of being passed as a parameter,
allowing SQL injection.
 * @problem.severity error
 * @tags security
 *       external/cwe/cwe-089
 */
import python
import semmle.python.dataflow.new.DataFlow
import semmle.python.dataflow.new.TaintTracking
import semmle.python.ApiGraphs

class SqlInjectionConfig extends TaintTracking::Configuration {SqlInjectionConfig() {this = "SqlInjectionConfig" }
override predicate isSource(DataFlow::Node source) {exists(DataFlow::Node n |n.asExpr() = any(Subscript s |s.getObject().(Name).getId() = "headers").getItem(_) or
      source.asExpr() = any(Call c |c.getFunc().(Attribute).getAttrName() = "get" and
        c.getFunc().(Attribute).getObject().(Name).getId() = "headers"
      )
    )
  }override predicate isSink(DataFlow::Node sink) {
exists(DataFlow::Node n |n.asExpr() = any(Call c |c.getFunc().(Attribute).getAttrName() = "execute" or
        c.getFunc().(Attribute).getAttrName() = "executemany" or
        c.getFunc().(Attribute).getAttrName() = "executescript"
      ) and
      sink = n
    )
  }override predicate isAdditionalTaintStep(DataFlow::Node node1,DataFlow::Node node2) {
any(FString fstr).getAFormattedValue() = node1.asExpr() and
    node2.asExpr() = fstr
  }}from DataFlow::PathNode source,DataFlow::PathNode sink,SqlInjectionConfig config
where config.hasFlowPath(source,sink)
select sink.getNode(),source,sink,"User-controlled input from Authorization header reaches database execute() call,allowing SQL injection."

🤖 本文由漏洞情报系统自动聚合生成 · 2026-08-09 12:02 · 数据源: NVD/GitHub-Advisory/OSV/CISA-KEV/Exploit-DB/PoC-in-GitHub + 检测规则库

[!] CONTACT_CHANNELS

如需商务合作、技术咨询或漏洞反馈，请通过以下离岸节点联系作者。

> PING_AUTHOR (@A1RedTeam)