文章总结： CVE-2026-42208是LiteLLM开源LLM代理网关中的严重预认证SQL注入漏洞，CVSS评分9.8分。攻击者无需凭证即可通过恶意Authorization请求头执行任意SQL语句，窃取API密钥、篡改配置并完全接管服务。影响版本为1.83.7之前，已在野利用。建议立即升级至1.83.7+版本，检查公网暴露面并监控日志中的SQL注入特征。
综合评分： 92
文章分类： 漏洞预警,漏洞分析,应急响应,解决方案,数据安全
[高危漏洞预警] LiteLLM 预认证SQL注入漏洞CVE-2026-42208
飓风网络安全
2026年4月29日 08:28
云南
在小说阅读器读本章
去阅读
项目 核心信息
CVE编号 CVE-2026-42208
漏洞类型 预认证SQL注入
风险等级 严重（Critical）
CVSS评分 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H（9.8分）
影响组件 LiteLLM 开源LLM代理网关
影响范围 LiteLLM 版本 < 1.83.7
安全补丁 LiteLLM 1.83.7 及以上版本
披露时间 2026年4月20日（官方安全公告）
在野利用状态 漏洞公开36小时内已出现大规模定向野利用，全球互联网暴露面实例持续被扫描攻击
LiteLLM是行业主流开源LLM代理中间件，可统一对接OpenAI、Anthropic、Azure OpenAI等上百款大模型API，集中实现路由转发、负载均衡、权限管控、计费审计等核心能力，广泛应用于企业级AI应用、SaaS服务、多模型管理平台的核心基础设施层。
本次披露的CVE-2026-42208是一处无需任何有效凭证即可触发的预认证高危SQL注入漏洞，攻击者仅需访问LiteLLM默认服务端口（4000），即可通过恶意构造的请求头执行任意SQL语句，窃取核心凭证、篡改业务配置，甚至完全接管AI网关服务，风险覆盖所有公网暴露的受影响版本实例。
一、漏洞技术深度分析
1.1 根本成因
漏洞核心源于LiteLLM的API密钥认证逻辑存在严重的安全编码缺陷：在对请求头Authorization: Bearer中的用户可控Token进行数据库校验时，未采用参数化查询（预编译语句），而是直接将用户输入字符串拼接进SQL查询语句，导致SQL注入漏洞。
更关键的是，该校验逻辑处于认证流程的前置环节，攻击者无需持有有效API密钥，即可向任意LiteLLM API路由（如/v1/chat/completions、/v1/models）发送恶意请求，触发注入漏洞，属于典型的预认证远程代码执行级高危缺陷。
1.2 完整触发链路
-
攻击者向目标LiteLLM服务的任意API端点发送HTTP请求，在Authorization请求头中植入恶意SQL片段，格式为Authorization: Bearer <恶意SQL注入载荷>；
-
服务端接收请求后，提取Bearer后的Token字符串，未做任何输入校验、转义处理；
-
服务端直接将用户可控的Token字符串拼接至SQL查询语句，用于校验API密钥的有效性；
-
后端数据库执行拼接后的恶意SQL语句，攻击者实现任意数据查询、篡改、删除，甚至写入恶意数据获取系统权限；
-
攻击者利用窃取的API密钥、上游厂商凭证，进一步实施AI服务滥用、数据窃取、横向渗透等后续攻击。
1.3 漏洞代码级还原
漏洞代码（修复前）
漏洞核心逻辑：API密钥校验环节的SQL字符串拼接
def verify_api_key(request):
# 提取用户可控的Bearer Token
auth_header = request.headers.get(“Authorization”, “”)
if not auth_header.startswith(“Bearer “):
return False
user_token = auth_header.replace(“Bearer “, “”).strip()
# 高危操作：直接字符串拼接SQL，无参数化处理
sql_query = f”SELECT * FROM LiteLLM_VerificationToken WHERE token = ‘{user_token}’ AND is_active = 1″
# 执行SQL查询
query_result = database.execute(sql_query).fetchone()
return query_result is not None
修复代码（1.83.7+版本）
官方修复方案为彻底替换字符串拼接逻辑，采用数据库原生的参数化查询，将用户输入作为不可执行的参数传递，从根本上杜绝SQL注入风险：
修复逻辑：参数化查询，分离SQL指令与用户输入
def verify_api_key(request):
auth_header = request.headers.get(“Authorization”, “”)
if not auth_header.startswith(“Bearer “):
return False
user_token = auth_header.replace(“Bearer “, “”).strip()
# 安全操作：参数化查询，用户输入仅作为参数传递
sql_query = “SELECT * FROM LiteLLM_VerificationToken WHERE token = %s AND is_active = 1”
# 执行预编译SQL，数据库不会将参数内容解析为SQL指令
query_result = database.execute(sql_query, (user_token,)).fetchone()
return query_result is not None
二、典型攻击载荷与手法
基础探测载荷
用于快速验证漏洞是否存在，是野利用扫描的核心载荷：
GET /v1/models HTTP/1.1
Host: <目标IP>:4000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Authorization: Bearer ‘ OR 1=1– –
该载荷通过OR 1=1构造永真条件，可绕过API密钥校验逻辑，同时验证注入点是否存在。
数据窃取核心载荷
攻击者已明确掌握LiteLLM的数据库表结构，定向窃取核心敏感表数据：
GET /v1/chat/completions HTTP/1.1
Host: <目标IP>:4000
Authorization: Bearer ‘ UNION SELECT 1,token,secret,3,4 FROM litellm_credentials– –
通过列数枚举技术匹配原查询的字段数量，直接提取litellm_credentials表中的上游厂商API凭证。
攻击手法特征
-
定向精准攻击：不同于通用botnet的广撒网扫描，野利用攻击者提前完成LiteLLM架构与表结构分析，攻击载荷高度定制化，直接针对核心凭证表；
-
规避检测策略：采用IP轮换、代理池、低频次请求等方式，绕过传统WAF与流量监控规则；
-
全量数据窃取：攻击目标明确覆盖3类核心表：
◦ LiteLLM_VerificationToken：存储虚拟API密钥、主密钥、租户权限配置，窃取后可直接接管代理服务；
◦ litellm_credentials：存储OpenAI、Anthropic等上游LLM厂商的API密钥，窃取后可直接调用大模型服务，造成高额经济损失；
◦ litellm_config：存储系统环境配置、数据库连接信息、权限规则，为横向渗透提供支撑。
三、漏洞危害与业务影响
3.1 核心数据泄露风险
• LLM服务凭证泄露：攻击者可窃取上游大模型厂商API密钥，无限制调用高成本大模型，造成企业巨额账单损失，同时通过API访问企业私有模型、微调数据与知识库；
• 代理权限完全接管：窃取主密钥与虚拟API密钥后，可完全接管LiteLLM代理服务，篡改路由规则、访问控制策略，实现对企业所有LLM流量的劫持与监听；
• 业务敏感数据泄露：可窃取用户对话记录、计费数据、租户信息、员工账号等核心业务数据，引发合规风险与商业损失。
3.2 业务可用性破坏
• 攻击者可通过DELETE、DROP语句删除数据库表结构，导致LiteLLM服务完全瘫痪，企业AI应用全线中断；
• 可篡改计费规则、配额限制，导致业务计费体系混乱，引发用户纠纷与财务损失；
• 可植入恶意配置，将企业LLM流量转发至攻击者控制的恶意节点，实现持久化劫持。
四、自查与检测方案
4.1 版本自查（必做）
执行以下命令，快速确认当前LiteLLM版本是否受影响：
查看已安装的LiteLLM版本
pip show litellm | grep Version
容器环境执行
docker exec <容器ID> pip show litellm | grep Version
• 若版本号 < 1.83.7，属于受影响范围，需立即启动应急处置；
• 若版本号 ≥ 1.83.7，已修复该漏洞，无需升级。
4.2 公网暴露面自查
- 排查企业公网防火墙、安全组规则，确认是否对互联网开放LiteLLM默认4000端口；
- 排查测试环境、开发环境的LiteLLM实例，避免因弱防护、公网暴露导致攻击入口。
4.3 攻击行为检测
- 访问日志检测：全面排查LiteLLM服务访问日志，重点查找包含以下特征的请求：
Authorization请求头中包含’ OR、UNION SELECT、SLEEP(、– -、#等SQL注入特征字符串；
无有效API密钥的请求，却成功访问了需要鉴权的API端点；
来源IP为境外地址、匿名代理、恶意IP池的高频请求。
- 数据库审计检测：开启数据库全量审计日志，重点监控以下异常行为：
针对LiteLLM_VerificationToken、litellm_credentials、litellm_config核心表的全量查询、批量导出操作；
非业务时段的数据库写入、修改、删除操作；
出现异常的SQL报错信息，包含用户可控的Authorization头内容。
- 流量检测：在WAF、IPS设备中配置规则，监控HTTP请求头中包含SQL注入特征的流量，及时拦截攻击请求。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：飓风网络安全 《[高危漏洞预警] LiteLLM 预认证SQL注入漏洞CVE-2026-42208》