现在绝大多数企业落地私有化大模型、多厂商AI接入都会用LiteLLM做统一网关代理。它能统一OpenAI兼容接口、统一密钥管理、统一流量管控帮业务快速对接OpenAI、Anthropic、Azure、通义千问等几十种模型。但很多团队部署LiteLLM时只关注功能可用完全忽略其攻击面。多数生产环境默认开启调试接口、权限校验残缺、凭证明文存储、可被无认证直接打入RCE。加上2024–2026年连续爆出多起在野利用漏洞LiteLLM已经成为企业AI基础设施中最高危的突破口之一。本文从实战角度从零梳理LiteLLM完整攻击链路、拆解每一处可被利用的真实入口、给出可直接复制使用的排查脚本、加固配置和防御方案所有内容均贴合真实攻防对抗场景不做理论空泛堆砌。1. 先理清本质LiteLLM为什么极易被攻破用第一性原理看LiteLLM的核心定位就能看懂它所有安全问题的根源。LiteLLM不是普通的业务代理它是企业AI体系的核心中枢。这个中枢手里持有全网最核心的两类资产所有上游大模型厂商的API密钥以及全量业务对话的敏感数据。同时它的产品设计优先级长期偏向兼容性和易用性安全约束全部后置。开发阶段为了快速调试开放大量高危接口为了适配多厂商模型放开各类参数自定义权限为了降低部署门槛默认配置极度宽松。这就形成了致命安全短板最高价值资产搭配最宽松的默认策略最多的未收敛攻击入口。外界多数安全分析只罗列CVE漏洞编号不会讲透底层逻辑。LiteLLM真正的风险不在于某一个单独漏洞而是漏洞之间可以无缝串联形成从匿名访问到服务器接管、全网密钥窃取的完整攻击链。攻击者不需要复杂利用链只靠默认配置漏洞、权限绕过、接口未授权就能完成全链路渗透。1.1 LiteLLM全网流量架构攻防核心视角所有攻击行为都围绕三层流量架构展开看懂架构就能定位全部攻击入口。A[下游客户端] --|业务AI请求| B[LiteLLM AI网关]B --|转发模型请求| C[公有云LLM厂商OpenAI/Azure/Anthropic]B --|本地模型调用| D[私有化LLM服务]B -- E[网关核心模块]E -- E1[鉴权路由模块]E -- E2[密钥管理模块]E -- E3[RAG文件摄入模块]E -- E4[Guardrails代码校验模块]E -- E5[MCP工具调用模块]B -- F[存储层数据库/本地配置文件]F -- F1[存储厂商密钥/用户凭证/对话日志]下游是业务系统、用户终端、各类AI Agent请求全部汇聚到LiteLLM网关层负责鉴权、路由、转发、管控上游对接所有公有云和私有化大模型存储层持久化所有核心凭证和数据。整个架构没有天然隔离任意一层突破都能横向打通其他模块。下游可控流量可以打穿网关网关失守可以窃取上游所有模型密钥存储泄露直接兜底所有敏感资产。2. 全维度攻击面拆解实战可利用入口全覆盖我不做传统的分类罗列直接按照攻击者的渗透顺序拆解从外网预认证入口到权限绕过再到数据窃取最后代码执行持久化覆盖所有在野利用的攻击面。2.1 供应链攻击面最彻底的底层沦陷供应链是LiteLLM最高危、最容易被企业忽略的攻击面。很多团队通过pip直接安装、自动更新版本完全没有校验机制。2026年曝光的CVE-2026-33634证实攻击者盗用LiteLLM官方PyPI发布权限在1.82.7、1.82.8两个正式版本中植入恶意混淆代码。这个恶意代码无任何触发条件服务启动即自动执行。它会遍历服务器、容器内所有环境变量、配置文件、密钥文件抓取LLM厂商API Key、数据库密码、SSH私钥、云服务凭证通过RSA加密后主动外传攻击者服务器。这类攻击的危害远超普通Web漏洞。普通漏洞最多单服沦陷供应链投毒可以让企业所有部署LiteLLM的集群、测试机、开发机全部批量失守。除了官方包投毒衍生供应链风险同样高频。国内很多镜像源同步滞后、第三方离线安装包被篡改、Docker镜像非官方构建都会导致使用者安装带后门的版本。2.1.1 实战排查命令可直接复制# 查看当前LiteLLM版本pip show litellm# 校验安装包哈希官方安全包校验值piphashlitellm1.83.14# 检查是否存在恶意版本pip list|greplitellm|grep-E1.82.7|1.82.8生产环境必须严格禁止自动升级所有版本更新必须人工校验哈希值仅使用1.83.14及以上修复版本。2.2 预认证HTTP接口攻击面外网零门槛突破点LiteLLM默认对外开放大量接口绝大多数企业没有做外网访问限制匿名用户可以直接调用高危接口。这是外网渗透的第一入口。2.2.1 预认证SQL注入CVE-2026-42208网关鉴权模块直接读取HTTP请求的Bearer参数未做参数化过滤直接拼接SQL语句查询用户密钥和权限。外网攻击者无需任何登录构造恶意Authorization请求头就能执行任意SQL语句全量导出数据库数据。其中包含所有厂商LLM密钥、管理员账号密码、用户权限配置、历史对话日志。这个漏洞的核心危害是零门槛、全量脱库、无任何防御前置在野利用频率极高。2.2.2 Host头注入与路由绕过LiteLLM的部分权限校验逻辑依赖Host头判断请求来源信任客户端可控参数。攻击者伪造自定义Host头就能绕过前端权限拦截直接访问后台管理员专属接口。该漏洞无法单独造成最大危害但可以和MCP命令注入、配置篡改漏洞串联实现匿名无认证RCE是完整攻击链的关键衔接环节。2.2.3 全域SSRF漏洞持久在野利用LiteLLM多个核心接口支持用户自定义URL参数没有内网网段拦截、没有可信域名白名单造成全场景SSRF风险。/v1/chat/completions接口允许用户自定义api_base参数网关会携带自身的厂商密钥转发请求到攻击者指定的任意地址。攻击者可以直接捕获网关绑定的OpenAI、Azure、通义千问密钥劫持企业AI调用额度。RAG文件摄入接口/v1/rag/ingest的file_url参数支持访问任意内网地址。攻击者可以扫描内网存活服务、访问云主机169.254元数据网段窃取云服务器临时凭证、接管云资源。连通性测试接口/health/test_connection同样无限制出站可作为持久化内网扫描、内网服务探测的代理跳板。2.2.4 默认未关闭的高危调试接口这是90%企业都会踩的坑。LiteLLM开发调试接口不会在生产环境自动关闭很多团队上线后直接对外开放。/guardrails/test_custom_code 接收用户自定义Python代码通过原生exec()执行无沙箱隔离、无高危函数拦截。攻击者可以直接写入系统命令、读写服务器文件、反弹Shell、获取服务器权限。/mcp-rest/test/connection MCP工具测试接口存在命令拼接漏洞用户输入参数直接拼接系统指令结合Host头绕过即可实现无认证远程代码执行。/config/update 配置更新接口缺失管理员权限校验任意低权限用户甚至匿名用户在部分版本中可直接篡改全局配置加载恶意自定义处理器。2.3 认证授权攻击面完整提权链路LiteLLM的权限体系分为四层匿名用户、普通业务用户、组织管理员、超级代理管理员。官方设计的层级隔离在代码实现中完全失效存在多条低成本提权路径。多数安全团队只关注外网漏洞忽略内网横向提权。一旦业务侧被攻破攻击者拿到普通用户密钥就能通过LiteLLM的权限漏洞直接接管整个AI网关。2.3.1 密钥鉴权绕过CVE-2026-12773 漏洞显示LiteLLM对Bearer密钥的校验逻辑存在逻辑短路。构造特殊格式的密钥头服务会直接跳过鉴权逻辑放行所有API请求。攻击者无需有效密钥即可使用全部代理能力。2.3.2 子密钥通配权限越权/key/generate 接口用于生成子密钥用于业务侧权限隔离。但接口未校验当前用户的最大权限范围普通用户可以在生成密钥时配置allowed_routes为[“/*”]创建拥有全站权限的子密钥。这意味着任意低权限用户都能自制超级密钥访问管理员接口、读取所有密钥、修改网关配置。2.3.3 用户角色任意篡改/user/update 接口没有字段级权限控制认证用户可以自主修改自身的user_role字段直接将普通身份提升为proxy_admin超级管理员。这个漏洞的危害极其直观只要拿到任意一个有效用户账号瞬间拿下网关最高权限无任何中间阻碍。2.3.4 弱哈希凭证存储早期版本LiteLLM对用户密码采用无盐SHA256哈希存储接口可直接返回哈希值。攻击者获取哈希后可直接用于登录无需爆破、无需破解。新版本虽然修复但大量存量生产环境仍保留旧数据。2.4 数据存储攻击面核心资产裸奔LiteLLM的数据库和本地配置文件集中存储企业AI体系的全部核心资产没有分级脱敏、没有加密防护。存储内容包含所有大模型厂商API密钥、数据库连接凭证、网关超级管理员密钥、全量用户账号权限、全量历史对话Prompt、RAG摄入的业务私密文件内容。攻击者通过SQL注入、RCE、权限提升任意一种方式就能批量导出所有数据。不仅造成资金损失恶意调用模型产生巨额账单还会泄露企业源代码、客户隐私、内部工单、商业机密。2.5 代码执行与沙箱逃逸攻击面服务器完全接管LiteLLM为了实现自定义风控、自定义工具能力开放了代码动态执行功能但没有做有效沙箱隔离沙箱仅靠简单黑名单过滤可轻松逃逸。Guardrails自定义代码模块是最高危的RCE入口攻击者可以绕过正则过滤导入os、subprocess模块执行系统命令读取/etc/passwd、读取配置密钥、写入后门文件、持久化控制服务器。配置篡改加载恶意脚本的方式更隐蔽。攻击者越权修改网关配置指定恶意Python处理器路径网关重启或刷新配置后自动执行恶意代码实现长期潜伏很难被安全设备检测。2.6 AI原生攻击面业务层隐性泄露除了传统网络漏洞LiteLLM还存在AI架构特有的攻击面这类漏洞不会触发WAF告警但会直接造成数据泄露。下游用户可控Prompt可构造隐式提示注入诱导网关输出自身存储的密钥、读取RAG库中的私密文件、调用MCP工具访问内网资源。同时网关默认记录全量对话日志所有用户输入的私密信息、业务数据都会持久化存储权限一旦泄露批量数据泄露风险极高。2.7 部署配置攻击面人为放大所有风险绝大多数LiteLLM安全事件根源不是0day漏洞而是部署配置不规范把高危漏洞直接暴露在公网。生产环境普遍存在几个致命配置问题调试接口未关闭、超级管理员默认弱密钥、管理接口无IP白名单、容器以root权限运行、无密钥轮换机制、无全量审计日志。这些配置问题会让原本需要复杂利用的漏洞变成零门槛一键利用直接放大所有安全风险。3. 真实在野攻击链完整复现单独看每一个漏洞风险有限但攻击者会将漏洞串联形成完整渗透链路。下面三条是目前真实在野利用的核心攻击链完全贴合实战对抗场景。3.1 外网匿名无认证RCE攻击链1[外网匿名访问] -- 2[伪造Host头绕过鉴权]2 -- 3[调用MCP测试接口命令注入]3 -- 4[获取服务器系统权限RCE]4 -- 5[读取本地配置与数据库密钥]5 -- 6[脱库获取全量厂商密钥管理员账号]6 -- 7[接管全网AI网关资产]整条链路无需任何账号权限、无需伪造复杂载荷默认配置即可成功利用危害等级满级。3.2 低权限用户内网提权攻击链1[获取普通用户API密钥] -- 2[调用key/generate生成通配权限子密钥]2 -- 3[调用user/update篡改自身角色为超级管理员]3 -- 4[越权修改网关全局配置]4 -- 5[加载恶意代码实现沙箱逃逸]5 -- 6[服务器持久化控制]企业内网横向渗透中这条链路使用率最高业务系统一旦沦陷AI网关会瞬间失守。3.3 SSRF密钥窃取攻击链1[下游可控AI请求] -- 2[自定义api_base指向攻击者服务器]2 -- 3[LiteLLM携带自有厂商密钥转发请求]3 -- 4[攻击者捕获有效LLM密钥]4 -- 5[恶意调用模型产生巨额账单/泄露数据]4. 落地式安全排查脚本与检测方案我提供一套完整可直接部署的检测脚本覆盖版本检测、高危接口扫描、弱配置检测、权限漏洞检测企业可直接用于日常安全巡检。4.1 本地环境一键排查脚本#!/bin/bash# LiteLLM 本地安全合规排查脚本 V1.0echo[] 检测LiteLLM版本信息pip show litellmecho[] 检测恶意风险版本pip list|greplitellm|grep-E1.82.7|1.82.8echo[] 检测是否开启调试高危接口grep-rtest_custom_code\|mcp-rest/test/etc/litellm/2/dev/nullgrep-rdebugtrue/etc/litellm/2/dev/nullecho[] 检测默认弱密钥配置grep-rmaster_keytest\|master_key123456/etc/litellm/2/dev/nullecho[] 检测密钥明文存储配置grep-rencrypt_keyfalse/etc/litellm/2/dev/nullecho[] 排查完成请根据结果逐项加固4.2 外网接口漏洞扫描脚本importrequestsimportsys targetsys.argv[1]vuln_paths[/guardrails/test_custom_code,/mcp-rest/test/connection,/config/update,/health/test_connection,/v1/rag/ingest]print([] 开始扫描LiteLLM高危未授权接口)forpathinvuln_paths:urltargetpathtry:resrequests.get(url,timeout3)ifres.status_code!401andres.status_code!403:print(f[!] 高危接口未授权:{url}状态码:{res.status_code})exceptExceptionase:print(f[-] 访问失败:{url})5. 生产环境全套加固配置可直接复制部署所有加固策略均适配生产环境不影响正常业务功能直接替换原有配置即可生效。5.1 核心配置文件安全加固# LiteLLM 安全加固 config.yaml# 1. 关闭所有调试能力debug:falsedisable_test_endpoints:true# 2. 强制密钥加密存储encrypt_key:true# 3. 限制接口访问权限require_admin_for_all_config_updates:truedisable_public_routes:true# 4. SSRF白名单严格限制allowed_api_base_domains:-api.openai.com-azure.openai.com-anthropic.comblock_private_ip:true# 5. 禁用高危代码执行能力disable_custom_code_exec:truedisable_mcp_test_endpoints:true# 6. 开启全量审计日志audit_logs:truelog_sensitive_data:false5.2 网络层防护策略外网防火墙直接拦截所有内网网段出站请求彻底阻断SSRF对内网探测管理接口仅放行企业内网IP段禁止外网访问统一封禁所有测试、调试类接口路由。5.3 权限体系加固策略禁止普通用户生成通配权限子密钥后端强制校验子密钥路由范围关闭用户自主修改角色权限的接口能力所有管理员密钥按月强制轮换数据库凭证、模型密钥独立加密存储杜绝明文落地。6. 风险分级与优先级落地标准为方便企业快速落地整改我将所有风险划分为三级明确修复优先级。极高风险必须立即整改供应链恶意版本、预认证SQL注入、无认证RCE、外网开放调试接口。这类风险可被批量在野利用失守直接全网沦陷。高风险72小时内完成加固子密钥越权、角色篡改、全量SSRF、代码沙箱逃逸。这类漏洞可实现内网横向接管危害极高。中风险常态化迭代优化弱哈希存储、提示注入、日志明文泄露、密钥长期不轮换。这类风险不会瞬间失守但会造成持续性数据泄露隐患。7. 总结LiteLLM的安全问题本质是高价值基础设施过度追求易用性牺牲了安全边界。它的攻击面不是零散的单个漏洞是一套完整、可串联、可批量利用的渗透体系。企业防护不能只靠打补丁、升级版本必须从供应链校验、网络边界、接口权限、数据存储、代码执行、运维配置全链路收紧策略。版本升级只是基础配置加固、持续巡检、权限收敛才是核心防御手段。互动提问1. 你的企业生产环境是否还在使用 LiteLLM 低于1.83.14的版本2. 部署 LiteLLM 时是否默认关闭了所有调试测试接口欢迎在评论区留言交流。
