文章总结： 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 完整触发链路

1. 攻击者向目标LiteLLM服务的任意API端点发送HTTP请求，在Authorization请求头中植入恶意SQL片段，格式为Authorization: Bearer <恶意SQL注入载荷>；

2. 服务端接收请求后，提取Bearer后的Token字符串，未做任何输入校验、转义处理；

3. 服务端直接将用户可控的Token字符串拼接至SQL查询语句，用于校验API密钥的有效性；

4. 后端数据库执行拼接后的恶意SQL语句，攻击者实现任意数据查询、篡改、删除，甚至写入恶意数据获取系统权限；

5. 攻击者利用窃取的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凭证。

攻击手法特征

1. 定向精准攻击：不同于通用botnet的广撒网扫描，野利用攻击者提前完成LiteLLM架构与表结构分析，攻击载荷高度定制化，直接针对核心凭证表；

2. 规避检测策略：采用IP轮换、代理池、低频次请求等方式，绕过传统WAF与流量监控规则；

3. 全量数据窃取：攻击目标明确覆盖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 公网暴露面自查

1. 排查企业公网防火墙、安全组规则，确认是否对互联网开放LiteLLM默认4000端口；
2. 排查测试环境、开发环境的LiteLLM实例，避免因弱防护、公网暴露导致攻击入口。

4.3 攻击行为检测

1. 访问日志检测：全面排查LiteLLM服务访问日志，重点查找包含以下特征的请求：

Authorization请求头中包含’ OR、UNION SELECT、SLEEP(、– -、#等SQL注入特征字符串；

无有效API密钥的请求，却成功访问了需要鉴权的API端点；

来源IP为境外地址、匿名代理、恶意IP池的高频请求。

2. 数据库审计检测：开启数据库全量审计日志，重点监控以下异常行为：

针对LiteLLM_VerificationToken、litellm_credentials、litellm_config核心表的全量查询、批量导出操作；

非业务时段的数据库写入、修改、删除操作；

出现异常的SQL报错信息，包含用户可控的Authorization头内容。

3. 流量检测：在WAF、IPS设备中配置规则，监控HTTP请求头中包含SQL注入特征的流量，及时拦截攻击请求。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：飓风网络安全 《[高危漏洞预警] LiteLLM 预认证SQL注入漏洞CVE-2026-42208》