摘要： 开源AI网关项目LiteLLM近日被曝存在严重预认证SQL注入漏洞（CVE-2026-42208）。该漏洞已在野外被活跃利用，攻击者无需任何登录凭证即可从PostgreSQL数据库中批量提取云服务商API密钥与企业级AI供应商凭证。本文从漏洞原理、攻击时间线、实际影响及修复方案四个维度，梳理这一事件的完整脉络。

---

一、事件背景：AI代理中枢成攻击新靶点

LiteLLM在GitHub上拥有超过22,000个星标，是当下最活跃的开源AI网关之一。它的核心定位是充当"统一路由层"——企业只需对接LiteLLM这一个入口，就能无缝调度OpenAI、Anthropic Claude、AWS Bedrock、Azure OpenAI等主流大模型服务，同时完成计费统计、速率限制和密钥管理。

正是这种"中枢代理"的角色，让LiteLLM的本地数据库成了高价值情报的聚集地。平台默认使用PostgreSQL存储三类关键数据：虚拟API密钥（VerificationToken）、供应商接入凭证（Credentials）以及环境配置参数（Config）。一旦数据库防线被突破，意味着攻击者可以直接拿到企业通往各大云AI平台的"万能钥匙"。

Sysdig威胁研究团队的监测数据显示，这次漏洞的利用方式并非普通的自动化扫描，而是一次精心策划的定向渗透。

---

二、漏洞根因：一个单引号绕过的认证前注入

CVE-2026-42208的本质是一个预认证阶段的SQL注入。问题出在LiteLLM处理HTTP请求Authorization Bearer头部的逻辑上。

在正常的认证流程中，系统应当对用户提交的令牌进行严格的参数化查询或转义处理。然而受影响版本（1.81.16至1.83.6）在这一环节出现了疏漏——当攻击者在伪造的令牌中插入单引号（例如构造sk-litellm'这类载荷）时，后端直接将用户输入拼接进了SQL查询语句。

结果就是：攻击者甚至不需要知道任何合法账号的密码，只要能够访问到LiteLLM代理暴露的端口，就可以通过HTTP客户端发送精心构造的请求，在认证发生之前直接向PostgreSQL数据库下发任意命令。

从技术分类上看，这属于典型的"认证前注入"（Pre-Auth SQLi），其危害等级远高于需要登录后才能触发的二次注入。因为攻击面是全网可达的，任何暴露在互联网上的实例都处于无差别攻击范围内。

---

三、攻击时间线：36小时内的精准打击

漏洞披露的节奏本身就值得警惕。

2026年4月24日，GitHub全球咨询数据库（GHSA）正式收录CVE-2026-42208。Sysdig的遥测数据表明，仅36小时7分钟后，首次利用尝试便出现在蜜网中。这个响应速度在近年来的开源组件漏洞利用中属于极快的一档，说明攻击者很可能在漏洞公开前就已经完成了情报收集和武器化准备。

更耐人寻味的是攻击者的行为模式。与常见的"撒网式"漏洞扫描不同，这次入侵呈现出三个明显的定向特征：

第一，目标表高度精准。 攻击载荷明确指向LiteLLM_VerificationToken、litellm_credentials和litellm_config三张表，没有进行无意义的库遍历。这说明攻击者对LiteLLM的数据库Schema有深入了解，知道哪里藏着"值钱"的数据。

第二，载荷构造贴合实际模式。 攻击者根据真实的数据库结构动态调整SQL注入语句的语法和字段名，而非套用通用模板。这种"定制化"程度通常出现在有内网情报或长时间逆向研究的场景中。

第三，攻击源相对集中。 所有恶意请求均来自同一自治系统（AS）下的两个IP地址：65.111.27.132和65.111.25.67。IP聚合度如此之高，进一步排除了随机扫描的可能性，指向有组织的针对性数据窃取行动。

---

四、实际影响：这不仅仅是Web应用层面的漏洞

很多安全从业者习惯把SQL注入归类为"传统Web漏洞"，但放在AI网关这个特定场景下，CVE-2026-42208的连锁反应更接近云账户全面沦陷。

一旦数据库中的供应商凭证被提取，攻击者可以：

• 直接调用企业付费的OpenAI、Anthropic或AWS Bedrock API，产生高额账单；

• 利用窃取的云凭证横向移动至企业的AWS、Azure或GCP基础设施；

• 通过环境配置表中的内部网络参数，绘制目标企业的云架构拓扑；

• 长期潜伏，持续消耗AI配额或窃取模型推理数据。

对于将LiteLLM部署为生产环境AI入口的中大型企业而言，这相当于把"API网关"变成了"数据泄露网关"。

---

五、紧急修复：升级、轮换、监控三步走

LiteLLM维护团队已在1.83.7版本中修复该漏洞，核心改动是完善了数据库查询的参数化防护，杜绝了用户输入直接拼接SQL的可能。

如果你正在使用1.81.16到1.83.6之间的任何版本，请立即执行以下操作：

1. 升级至1.83.7或更高版本

这是阻断漏洞利用链的最直接手段。考虑到该攻击无需认证且对任何暴露实例均有效，延迟升级的风险极高。

2. 默认"已泄露"原则进行凭证轮换

由于攻击发生在认证之前，Web访问日志中可能不会留下明显的登录失败记录。因此，所有暴露在互联网上的脆弱实例都应被视为已遭入侵。需要立即轮换：

• 所有虚拟API密钥（Virtual Keys）

• LiteLLM主密钥（Master Key）

• 存储在litellm_credentials表中的各供应商接入凭证

3. 审查上游计费与日志

• 检查OpenAI、Anthropic、AWS Bedrock等上游平台的计费仪表盘，关注异常API调用量和Token消耗峰值；

• 回溯Web服务器访问日志，检索包含SQL关键字或sk-litellm'特征字符串的请求记录；

• 如果LiteLLM部署在容器或Kubernetes环境中，同时审查Pod网络流量日志，确认是否存在异常出站连接。

4. 网络层加固

将LiteLLM代理实例从公网直接暴露改为前置API网关或VPN/零信任架构之后，限制仅允许可信IP段访问管理端口。AI网关作为昂贵云凭证的集中存储节点，其安全优先级应当与核心数据库同级。