AI网关LiteLLM遭漏洞链攻击，默认账户致全面接管风险

事件全景

2026年6月15日，Obsidian Security公开披露了一组针对开源AI网关LiteLLM的漏洞链。攻击起点很不起眼：LiteLLM默认的低权限账户（internal_user）。终点是服务器上的任意代码执行。该漏洞链由三个CVE组成——CVE-2026-47101（授权绕过）、CVE-2026-47102（权限提升）、CVE-2026-42271（命令注入），加上同一披露周期修复的沙箱逃逸漏洞CVE-2026-40217。Obsidian Security为完整攻击链打出CVSS 9.9。LiteLLM维护方BerriAI在2026年5月2日发布的v1.83.14-stable中修复了所有问题。
CISA已将CVE-2026-42271加入KEV目录，说明该漏洞已有在野利用。从漏洞公开到大规模扫描出现，间隔不到两个月。AI基础设施正成为高价值目标——这句话已经不新鲜了，但这组漏洞是一个新的例证。


技术拆解

攻击者从一个internal_user账号起步。LiteLLM的权限模型允许低权限用户创建虚拟API密钥，但这些密钥本应受allowed_routes字段约束。CVE-2026-47101的根因在存储层：服务器在写入用户提交的allowed_routes字段时，没有和用户角色做比对。一个internal_user可以提交allowed_routes: ["/*"]，把通配符写进自己的密钥。
问题不止于此。LiteLLM的请求路由网关不仅用这个字段收缩权限，还把它当成一次隐式的授权：只要密钥的allowed_routes包含某条路由，网关就放行，不管用户原本有没有权限。持有["/*"]密钥的internal_user因此可以访问所有管理端点和测试端点。这是个相当典型的"字段语义被滥用"的bug——开发者的本意是用字段限制权限，但实现上反而把它变成了授权凭据。
通路打开后，攻击者抵达/user/update端点（CVE-2026-47102）。该端点允许用户编辑自己的记录，但没对可修改字段做限制。攻击者在更新自己记录时塞进user_role: "proxy_admin"，服务器照单全收，一个普通用户瞬间变成管理员。VulnCheck给这个漏洞的CVSS 4.0评分是8.7。
拿到管理员权限后，攻击者有两条路可以走到RCE。
第一条路：Custom Code Guardrail（CVE-2026-40217）。该功能允许管理员提交Python代码并通过exec()执行。LiteLLM在调用exec()时传入了一个不含__builtins__的globals字典，试图构造一个沙箱。但Python的exec()在globals为空时会自动注入完整的builtins模块——__import__、open、eval全都回来了。攻击者只需一条os.system载荷就能拿到反向Shell。这种"空builtins触发自动注入"的行为在Python安全研究里是个老话题了，LiteLLM踩了进来。
第二条路：MCP测试端点（CVE-2026-42271）。/mcp-rest/test/connection接受用户提交的command和args参数，直接通过子进程执行。值得注意的是，通过CVE-2026-47101拿到访问权的低权限用户也能直接调用这个端点——它不需要管理员身份，只要路由可达就行。这意味着这条路径可以绕过CVE-2026-47102单独使用。
独立安全公司X41 D-Sec还发现了/guardrails/test_custom_code游乐场端点的另一条路径：端点设置了基于正则表达式的黑名单，但攻击者可以用运行时字节码重写技术绕过字符串匹配，同样完成沙箱逃逸。字符串黑名单对抗代码执行从来都是脆弱的，这条额外路径印证了这一点。
整个链条的依赖关系很明确：CVE-2026-47101打开路由通路，CVE-2026-47102提升角色到管理员，CVE-2026-42271或CVE-2026-40217完成代码执行。其中47101+42271可以独立成链，不依赖47102。


影响范围

LiteLLM是开源AI网关，把超过100个模型提供商的API（OpenAI、Anthropic、Gemini、Bedrock、Azure等）统一成OpenAI兼容接口，在企业AI基础设施里通常扮演中枢角色。一旦服务器被完全控制，攻击者能拿到：

• 所有模型提供商的API密钥：明文存在环境变量或配置文件里；数据库里加密存储的密钥，其解密用的salt key也能从配置中提取。
• 数据库连接URL：包含数据库地址和凭据，攻击者可以导出或删除历史记录。
• 经过网关的所有提示词和模型响应：实际部署里这些数据往往带着PII、源代码、内部工单，甚至粘贴在对话里的密钥。
• OAuth令牌和工具凭据：如果LiteLLM作为MCP或代理网关运行，这些凭据也在暴露范围。
  

我们认为，比数据被读取更严重的是响应被篡改。LiteLLM坐在AI代理和模型之间，一旦被攻陷，攻击者可以伪造工具调用、重写安全检查上下文为"已批准"，劫持下游AI代理的行为。举例来说，一个依赖AI网关做代码审查的企业，攻击者可以篡改模型输出绕过安全审批，往生产环境注入恶意代码。这把漏洞从"数据泄露"升级到了"AI供应链投毒"。


归因与在野利用

Obsidian Security的披露没有将漏洞链归因到任何已知威胁行为体。CISA把CVE-2026-42271放进KEV，只能确认有在野利用，不知道是谁干的。
从LiteLLM的部署分布看，全球大量AI初创企业和大型企业的内部AI平台都在使用这个组件。攻击者的动机可能包括数据窃取、资源盗用（用泄露的API密钥调用付费模型），或者把它当成跳板渗透企业内网。截至目前，没有任何公开报告把这次利用和已知APT组织关联起来。但缺少归因不等于没有组织参与——相反，AI基础设施相关的漏洞利用在过去一年里持续吸引多方行为体，这点我们必须保持警惕。


防御建议

立即升级：升到v1.83.14-stable或更高版本，四个CVE全部修复。
收紧默认配置：

• 禁用不需要的测试端点，尤其是MCP测试功能。可以在配置文件里设置allowed_routes白名单，或者用反向代理只暴露必要的路由。
• 限制管理后台的访问来源IP，只允许受信管理网络访问LiteLLM管理界面。
• 删除或禁用默认的internal_user账户，改用独立服务账号并分配最小权限。
  

审计现有虚拟密钥：导出所有虚拟API密钥的allowed_routes字段，人工检查有没有异常的/或/user/等通配符覆盖。LiteLLM的管理API支持批量导出。
日志与监控：

• 监控Web日志中对/mcp-rest/test/、/guardrails/test_custom_code、/user/update等端点的异常POST请求，重点看带command、args、user_role参数的有效载荷。
• 记录用户角色变更事件，检测internal_user到proxy_admin的越权提升。
• 做关联分析，识别短时间内的多步调用链：创建虚拟密钥 → 访问/user/update → 执行测试端点请求。
  

网络分区：把LiteLLM部署在独立的安全子网，出站流量只放行到模型提供商API，禁止直接访问公网。内网实施微隔离，阻断横向移动。


技术附录

ATT&CK 映射表

TTP编号	名称	在攻击链中的使用
T1078	Valid Accounts	利用LiteLLM默认的internal_user低权限账户进行初始访问
T1068	Exploitation for Privilege Escalation	利用CVE-2026-47102修改user_role字段实现权限提升
T1203	Exploitation for Client Execution	通过CVE-2026-42271的MCP测试端点执行命令，或通过CVE-2026-40217的Python沙箱逃逸执行代码
T1552	Unsecured Credentials	从LiteLLM配置中提取明文API密钥、salt key和数据库连接URL

完整IOC列表

基于当前公开信息，未发现与此次漏洞链利用相关的特定网络或文件型IOC（如IP地址、恶意文件Hash）。以下列举可观测的攻击行为指标，可用于检测潜在利用：

IOC类型	值 / 模式	核验理由
HTTP请求URI	POST /mcp-rest/test/connection	CVE-2026-42271利用端点，参数中应包含command和args字段
HTTP请求URI	POST /guardrails/test_custom_code 或 POST /guardrails/custom_code	CVE-2026-40217和X41字节码重写攻击的目标端点
HTTP请求URI	POST /user/update 或 POST /user/bulk_update 包含user_role参数	CVE-2026-47102提升权限的特征
虚拟密钥字段	allowed_routes包含/*或/user/*等通配符	CVE-2026-47101绕过授权后的残留指标，可在数据库中检索
用户角色变更	用户记录中user_role从internal_user变为proxy_admin	权限提升的直接证据，可通过LiteLLM审计日志获取
时间序列异常	同一IP在短时间内依次调用：创建密钥 → /user/update → 测试端点	攻击链的典型执行序列

检测规则（Sigma格式）

以下Sigma规则检测针对CVE-2026-42271的命令注入尝试。
title: LiteLLM MCP Test Endpoint Command Injection (CVE-2026-42271)
id: a1b2c3d4-0000-0000-0000-000000000001
status: experimental
description: Detects POST requests to /mcp-rest/test/connection with suspicious command parameters, indicative of CVE-2026-42271 exploitation.
references:
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-42271
  - https://obsidiansecurity.com/research
tags:
  - attack.t1203
  - attack.initial_access
logsource:
  category: webserver
  product: apache
  service: access
detection:
  selection:
    http_method: 'POST'
    url_path: '/mcp-rest/test/connection'
  keywords_command:
    - 'command'
    - 'args'
  condition: selection and keywords_command
falsepositives:
  - Legitimate administrative testing from trusted IPs
level: high针对CVE-2026-47102的权限提升检测：
title: LiteLLM User Role Escalation (CVE-2026-47102)
id: a1b2c3d4-0000-0000-0000-000000000002
status: experimental
description: Detects modification of user role to proxy_admin via /user/update or /user/bulk_update endpoints.
references:
  - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-47102
tags:
  - attack.t1068
logsource:
  category: application
  product: litellm
  definition: 'LiteLLM application audit log or database change tracking'
detection:
  selection:
    endpoint: '/user/update' or '/user/bulk_update'
    changed_field: 'user_role'
    new_value: 'proxy_admin'
  condition: selection
falsepositives:
  - Authorized admin making changes from an admin account (filter by initial user role)
level: high

热心网友4

感谢楼主这么详细的拆解。这组漏洞链确实触目惊心，尤其是从低权限用户一路到RCE，每个环节都很典型但又很容易被忽视。我比较意外的是allowed_routes字段居然直接变成隐式授权凭证，感觉是设计时把“限制”和“授权”混为一谈了。 另外那个Python沙箱逃逸的点也让人后怕——很多人以为传个空globals就安全了，没想到Python会自动注入builtins，这算是个经典陷阱，但LiteLLM还是踩了进去。楼主提到CVE-2026-42271可以直接由低权限用户触发，不需要走提权，这条路径在野利用的可能性应该更高。 想请教一下，针对默认的internal_user账户，除了删除或禁用之外，有没有建议的替代方案？比如必须保留一个服务账号的话，在配置上要怎么加固才能避免类似的字段劫持？

热心网友5

这个分析很全面，把攻击链的逻辑讲得非常清楚。尤其是“allowed_routes字段从权限限制变成授权凭据”那一点，确实很典型的实现与意图背离。 提个操作层面的补充：除了升级版本，如果短时间内无法升级（比如某些环境走变更流程慢），建议在反向代理层（Nginx/HAProxy）直接阻断对 `/mcp-rest/test/connection` 和 `/guardrails/test_custom_code` 这两个端点的外部访问。毕竟CVE-2026-42271已经有KEV标记，优先堵死这条能低权限直达RCE的路径，能争取缓冲时间。 另外，内部审计虚拟密钥这个建议很关键。很多团队部署后就没有再回去查过那些自动生成的密钥权限，可能早就留下了隐患。

热心网友3

这篇分析非常有价值，把漏洞链的每个环节和背后的设计缺陷都讲得很清楚。特别是“字段语义被滥用”这点，确实很多网关类组件在权限校验上容易犯这种错——把本应只做限制的字段反过来当成了授权凭证。另外那个exec()沙箱的踩坑也很有代表性，“空builtins反而触发自动注入”这一点对很多不熟悉Python exec内部机制的人来说确实容易疏忽。整体来看，这篇干货很多。