现在绝大多数企业落地私有化大模型、多厂商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# 校验安装包哈希（官方安全包校验值）piphashlitellm==1.83.14# 检查是否存在恶意版本pip list|greplitellm|grep-E"1.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-E"1.82.7|1.82.8"echo"[+] 检测是否开启调试高危接口"grep-r"test_custom_code\|mcp-rest/test"/etc/litellm/2>/dev/nullgrep-r"debug=true"/etc/litellm/2>/dev/nullecho"[+] 检测默认弱密钥配置"grep-r"master_key=test\|master_key=123456"/etc/litellm/2>/dev/nullecho"[+] 检测密钥明文存储配置"grep-r"encrypt_key=false"/etc/litellm/2>/dev/nullecho"[+] 排查完成，请根据结果逐项加固"

4.2 外网接口漏洞扫描脚本

importrequestsimportsys target=sys.argv[1]vuln_paths=["/guardrails/test_custom_code","/mcp-rest/test/connection","/config/update","/health/test_connection","/v1/rag/ingest"]print("[+] 开始扫描LiteLLM高危未授权接口")forpathinvuln_paths:url=target+pathtry:res=requests.get(url,timeout=3)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:false

5.2 网络层防护策略

外网防火墙直接拦截所有内网网段出站请求，彻底阻断SSRF对内网探测；管理接口仅放行企业内网IP段，禁止外网访问；统一封禁所有测试、调试类接口路由。

5.3 权限体系加固策略

禁止普通用户生成通配权限子密钥，后端强制校验子密钥路由范围；关闭用户自主修改角色权限的接口能力；所有管理员密钥按月强制轮换；数据库凭证、模型密钥独立加密存储，杜绝明文落地。

6. 风险分级与优先级落地标准

为方便企业快速落地整改，我将所有风险划分为三级，明确修复优先级。

极高风险必须立即整改：供应链恶意版本、预认证SQL注入、无认证RCE、外网开放调试接口。这类风险可被批量在野利用，失守直接全网沦陷。

高风险72小时内完成加固：子密钥越权、角色篡改、全量SSRF、代码沙箱逃逸。这类漏洞可实现内网横向接管，危害极高。

中风险常态化迭代优化：弱哈希存储、提示注入、日志明文泄露、密钥长期不轮换。这类风险不会瞬间失守，但会造成持续性数据泄露隐患。

7. 总结

LiteLLM的安全问题，本质是高价值基础设施过度追求易用性，牺牲了安全边界。它的攻击面不是零散的单个漏洞，是一套完整、可串联、可批量利用的渗透体系。

企业防护不能只靠打补丁、升级版本，必须从供应链校验、网络边界、接口权限、数据存储、代码执行、运维配置全链路收紧策略。版本升级只是基础，配置加固、持续巡检、权限收敛才是核心防御手段。

互动提问

1. 你的企业生产环境是否还在使用 LiteLLM 低于1.83.14的版本？

2. 部署 LiteLLM 时是否默认关闭了所有调试测试接口？欢迎在评论区留言交流。