一把普通账号钥匙，打开AI网关的大门：LiteLLM两大高危漏洞深度解析

原创

威胁情报中心
威胁情报中心

奇安信威胁情报中心

2026年10月15日 15:10
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

漏洞分析 · AI 网关安全 · LLM Gateway

一把普通账号钥匙，打开 AI 网关的大门

LiteLLM两大高危漏洞深度解析

Check Point Research 披露最流行的开源 LLM 网关 LiteLLM 两枚高危漏洞（CVE-2026-35029 / CVE-2026-59823）：一个低权限账号即可任意读文件、接管管理员乃至远程代码执行；SSRF 还能窃走网关托管的全部上游 API Key。

· LiteLLM　· CVE-2026-35029　· CVE-2026-59823　· 2026.10

事件速览：Check Point Research 披露开源 LLM 网关 LiteLLM 存在多个高危漏洞（CVE-2026-35029、CVE-2026-59823）。攻击者仅需一个低权限账号，即可实现任意文件读取、管理员账号接管乃至远程代码执行；另可通过 SSRF 窃取网关托管的全部大模型厂商 API Key。漏洞已在 LiteLLM 1.83.9 版本修复，低于该版本的部署均受影响。第三方蜜罐数据显示，相关利用特征的在野探测早已出现。

01 为什么盯上 LLM 网关

在大模型落地的架构里，LLM 网关（LLM Gateway）处在应用与模型供应商之间：应用不直接调用 OpenAI、Anthropic、Google 等厂商 API，而是统一把请求发给网关，由网关完成路由、负载均衡、限流、日志与用量统计。

这个位置决定了网关的“含金量”——它集中保管着所有上游模型厂商的 API Key、虚拟密钥、消费记录，往往还连着控制面数据库。拿下网关，约等于拿下整个组织 AI 栈的“保险柜钥匙”。

图1 | LLM 网关在 AI 架构中的位置与核心职能（图源：Check Point ）

LiteLLM 是该领域最流行的开源项目之一，提供 SDK 与网关（Proxy）两种形态，月下载量约 9700 万次，GitHub Star 超过 5.9 万，广泛内嵌于各类企业平台与内部 AI 工具中。也正因如此，它成为安全研究与攻击者共同关注的焦点：2026 年以来，LiteLLM 先后经历了 PyPI 投毒供应链事件、MCP 认证绕过漏洞（CVE-2026-59822，已被 CISA 列入 KEV 目录）、Pwn2Own 爱尔兰站现场攻破等一系列安全事件。

本文聚焦 Check Point Research 于 2026 年 10 月公开的两枚高危漏洞，其披露流程始于 2025 年 10 月，审计基线版本为 LiteLLM 1.77.7。

02 CVE-2026-35029：缺失的一行角色检查

2.1 漏洞本质

LiteLLM 代理暴露了管理接口 POST /config/update，用于在运行时修改代理配置，包括环境变量、模型列表和全局设置。问题出在该接口只做通用认证、不做角色校验：

• 在规范的实现中（如 /invitation/new 接口），代码会显式检查调用者是否具备 PROXY\_ADMIN 角色，否则直接抛错；
• 而 update\_config 函数仅依赖 user\_api\_key\_auth 这个通用认证依赖，拿到用户对象后没有再做任何角色判断，就径直执行配置写入。

2.2 绕过链条：四个环节层层失守

仅有函数级授权缺失还不够，真正让低权限用户“畅通无阻”的是 UI 会话令牌的宽松路由放行机制，整条链路如下：

1. UI 登录生成特殊令牌：任何用户登录 LiteLLM 管理界面时，后端都会为其生成一个临时 API Key，且该 Key 被显式绑定到名为 litellm-dashboard 的特殊团队；
2. 按 team\_id 粗暴分类：鉴权函数 common\_checks 仅凭 team\_id == \"litellm-dashboard\" 就把令牌归类为 “ui” 类型；
3. UI 令牌走宽松通道：被归类为 “ui” 的令牌会进入 \_is\_ui\_route() 检查，而非更严格的 \_is\_api\_route\_allowed()；
4. 前缀匹配酿成大错：UI 路由白名单中包含 /config（本意是允许界面读取配置），而匹配逻辑用的是 startswith 前缀匹配——/config/update 以 /config 开头，于是被直接放行。

四个环节叠加的结果是：任何拥有有效 UI 会话的用户，哪怕是最低权限的 Internal User，都能调用配置修改接口。

图2 | CVE-2026-35029 鉴权绕过判定流程图——任何 UI 会话用户均可触及 /config/update（图源：本文根据 Check Point Research 披露的代码逻辑整理绘制）

2.3 从一个接口到三种致命打法

拿到 /config/update 的写入能力后，攻击者可以组合出三条完整的攻击路径。

图3 | /config/update 攻击链总览——三条利用路径的技术细节（图源：本文根据 Check Point Research 披露内容整理绘制）

路径一：任意文件读取

/config/update 接受 environment\_variables 字段，会将键值对解密后直接写入 os.environ。其中 UI\_LOGO\_PATH 变量控制着 /get\_image 接口返回的文件路径——该接口把路径原样交给 FileResponse 返回，不做任何校验，且据第三方复现，该接口本身无需认证。

攻击者只需两步：

POST /config/update

{\"environment\_variables\": {\"UI\_LOGO\_PATH\": \"/etc/passwd\"}}

GET /get\_image

服务器即原样返回 /etc/passwd 内容。将路径换成 .env、配置文件等，即可批量收割厂商密钥、Master Key、数据库连接串。

路径二：管理员账号接管

UI 登录流程的凭据校验直接读取环境变量 UI\_USERNAME 与 UI\_PASSWORD，比对通过即授予完整的 PROXY\_ADMIN 权限。攻击者通过同样的环境变量注入把这两个值改成自己的凭据，随后用新凭据登录管理后台，即以默认 admin 身份接管整个网关——顺带还能把真正的管理员锁在门外。

图4 | 使用注入的 “hacker/hacker” 凭据登录，服务器接受请求并签发内置 admin 账号的 JWT（图源：Check Point）

图5 | 攻击者以默认管理员（default\_user\_id，角色 Admin）身份进入 LiteLLM 管理后台（图源：Check Point）

路径三：远程代码执行

LiteLLM 支持 pass-through（透传）端点，可将请求代理到外部服务或加载自定义适配器模块。/config/update 允许定义这类端点，其 target 参数支持以 s3:// 或 gcs:// 开头的远程地址——LiteLLM 会把对应的 Python 文件从对象存储下载下来，并通过 importlib 的 exec\_module() 直接执行。

攻击者在自己控制的 S3 存储桶中放置恶意 evil\_adapter.py（PoC 中仅创建 /tmp/litellm-pwned 标记目录验证执行），注册透传端点后，文件顶层代码即在网关进程内运行。换成反弹 Shell、窃密程序或挖矿木马，只是载荷问题。至此，攻击者在网关所在网络获得完整立足点。

图6 | LiteLLM 容器内出现 PoC 标记目录 /tmp/litellm-pwned，确认远程代码执行成功（图源：Check Point）

03 CVE-2026-59823：藏在嵌套参数里的 SSRF

与上述授权绕过相互独立，LiteLLM 一项名为 “Clientside LLM Credentials” 的文档化功能存在服务端请求伪造（SSRF）漏洞。

/chat/completions 等 LLM 接口接受请求体中的 user\_config 参数。当该参数存在时，LiteLLM 会用其中的配置现场构建一个全新的 Router，随后的模型调用都走这个攻击者可控的路由器——包括可以任意指定的 api\_base 地址。

值得强调的是，LiteLLM 原本设有 is\_request\_body\_safe 防护（源于早先一起 api\_base 劫持窃密报告），会拒绝请求体顶层的 api\_base、base\_url 参数；其 configurable\_clientside\_auth\_params 设置也会限制直接的 api\_base/api\_key 传入。但 user\_config 走的是另一条代码路径，防护只检查了请求体的最外层键，完全没有递归检查嵌套对象——把 api\_base 藏进 user\_config 里，guardrail 形同虚设。

攻击效果：网关把发往 OpenAI 等厂商的请求重定向到攻击者服务器，请求中携带的上游 API Key 随之落入攻击者手中；同时网关还可被当作跳板探测内网服务、云元数据接口等外部不可达的地址。

图7 | CVE-2026-59823 经 user\_config 参数重定向请求并窃取上游 API Key 的完整流程（图源：本号根据 Check Point Research 披露内容与官方修复补丁整理绘制）

图8 | 攻击者监听端（ncat）收到被重定向的 /chat/completions 请求，Authorization 头中携带上游 OpenAI sk-proj- 密钥（图中已脱敏）（图源：Check Point）

修复方式同样直白——补丁（PR #25827，commit 47214be）将 user\_config 加入 banned\_params 黑名单，并引入 ContextVar 机制防止内部可信调用被 HTTP 请求体伪造：

• banned\_params = [\"api\_base\", \"base\_url\"]

• banned\_params = [\"api\_base\", \"base\_url\", \"user\_config\"]

04 附加发现：口令哈希的双重失守

审计中还发现两个严重程度稍低、但同样值得警惕的问题（与既有发现重复，统一跟踪为 GHSA-69x8-hrgq-fjj8）：

• 口令哈希泄露：多个 API 接口会向认证用户返回其他用户的口令哈希，本应仅限管理员可见；结合前述 UI 令牌分类缺陷，低权限用户即可批量获取，用于离线破解。
• 不安全的口令哈希算法：LiteLLM 使用单次标准哈希、不加盐存储口令，而非 bcrypt/scrypt/Argon2 等专用算法。相同口令产生相同哈希（彩虹表可用），单次快速哈希令暴力破解成本极低。

05 在野威胁态势

漏洞并非停留在纸面：

• Zenity 蜜罐在 2026 年 2 月至 6 月间记录到约 3900 次 针对 LiteLLM 管理路由的请求，来自 73 个源 IP，其中约 1000 次 直指 /config/update；与公开利用链一致的文件读取载荷在 2026 年 5 月上旬现身。观测到的目标路径包括 /app/.env、/home/litellm/.env、/app/config.yaml 等典型凭据文件。
• 蜜罐流量中还频繁出现对默认 Master Key 的猜解（sk-1234、sk-litellm-master-key、sk-admin）。Wiz 此前的扫描显示，近十分之一的互联网暴露 LiteLLM 网关接受示例 Master Key sk-1234，或干脆无需任何认证——这类部署连“低权限账号”这个前提都不需要。
• LiteLLM 整体攻击面正被持续榨取：MCP 认证绕过 CVE-2026-59822 已进入 CISA KEV 目录并有在野利用记录（攻击者从进程内存提取 Master Key、窃取厂商密钥并植入 XMRig 挖矿程序）；2026 年 10 月的 Pwn2Own 爱尔兰站上，LiteLLM 亦被选手以路径穿越+不安全反序列化链条现场攻破。

06 处置与加固建议

1. 立即升级：所有环境升级至 LiteLLM 1.83.9 及以上（两个 CVE 均在该版本修复；其中 /config/update 授权修复于 1.83.0 引入）。注意 LiteLLM 常被作为组件内嵌在各类 AI 平台与内部工具中，需排查间接部署。
2. 轮换凭据：若网关在补丁前存在未授权访问迹象，应轮换全部上游模型厂商 API Key、虚拟密钥与 Master Key。
3. 审计账号与角色：清理不再需要的账号，实测验证低权限角色是否被真正约束——“配置上的权限”与“实际生效的权限”之间的鸿沟，正是 CVE-2026-35029 这类漏洞的温床。
4. 收缩暴露面：不要将 LiteLLM 管理面直接暴露于互联网；设置强 Master Key，杜绝默认值；通过反向代理限制管理类路由与 /mcp/ 等路径的外部访问。
5. 限制出网：收紧网关主机的出向流量，仅放行获批的模型厂商端点，阻断对云元数据地址与非必要内网地址的访问。
6. 将 AI 基础设施纳入常规安全评估：渗透测试与漏洞评估范围应覆盖 LLM 网关等 AI 工具链，与 Web 应用、云基础设施同等对待。

07 技术附录

7.1 漏洞信息汇总

7.2 MITRE ATT&CK 技术映射

7.3 失陷指标（IoC）与检测线索

请求特征（建议直接纳入 WAF/网关日志检测规则）：

典型攻击目标路径：/etc/passwd、/app/.env、/home/litellm/.env、/app/config.yaml

Zenity 蜜罐观测到的部分扫描源 IP：104.64.209.153、172.237.6.54、216.26.226.182、154.219.123.193、173.249.198.201、108.78.4.10、164.52.192.134、89.117.53.228、95.164.235.177

其他排查建议：关注对 /key/info、/key/list、/user/info、/team/info、/global/spend 等接口的枚举式突发访问；审计透传端点配置变更记录；检查网关进程外联行为中指向非常规对象存储或陌生主机的连接。

08 结语

LiteLLM 这组漏洞没有花哨的新攻击类别——缺失的授权检查、前缀匹配越权、动态模块加载 RCE、无盐口令存储，全是教科书级的老问题。真正值得警醒的是它们出现的位置：一个掌管全部模型密钥、处在 AI 流量咽喉的网关上。AI 基础设施在狂飙突进，但访问控制与输入校验这些“祖传基本功”，一项都省不得。

09 参考链接

1. Check Point Research — When LLM Gateways Go Wrong: Findings from LiteLLM
https://research.checkpoint.com/2026/when-llm-gateways-go-wrong-findings-from-litellm

2. Check Point 官方博客 — Check Point Research Discovers High-Risk Vulnerabilities in LiteLLM
https://blog.checkpoint.com/security/check-point-research-discovers-high-risk-vulnerabilities-in-litellm-one-of-the-most-widely-used-llm-gateways/

3. Zenity Labs — 漏洞复现与蜜罐观测
https://labs.zenity.io/post/admin-api-escalation-litellm

4. ThreatLandscape — CVE-2026-35029 技术分析与 IoC
https://threatlandscape.io/blog/cve-2026-35029-litellm-read-only-keys-take-over-the-ai-gateway

5. SentinelOne 漏洞库（CVE-2026-59823）
https://www.sentinelone.com/vulnerability-database/cve-2026-59823/

6. Miggo 漏洞库（CVE-2026-59823）
https://www.miggo.io/vulnerability-database/cve/CVE-2026-59823

7. GitHub 安全公告：GHSA-53mr-6c8q-9789 / GHSA-hx8v-g79f-8w5f / GHSA-69x8-hrgq-fjj8

8. Snyk 漏洞库（litellm）
https://security.snyk.io/package/pip/litellm

9. Wiz 研究相关（CVE-2026-59822 与默认密钥暴露面）
https://nhimg.org/litellm-mcp-auth-bypass-2026-cve-2026-59822-ai-gateway-keys

10. Pwn2Own Ireland 2026 赛况
https://infosec.ge/blog/pwn2own-ireland-2026-litellm-codex-day-one/