2014 年 4 月，一个名叫 Heartbleed（CVE-2014-0160）的漏洞震惊了全世界。它不在某个应用里，而在 OpenSSL——那个几乎整个互联网都依赖、却几乎没人真正关注过的加密库中。Heartbleed 的教训不是"开源软件有漏洞"，而是整个行业对基础设施层安全投入的系统性忽视。
十二年后的 2026 年 6 月，这个剧本正在 AI 行业重演。主角换成了 LiteLLM——一个被 CrewAI、DSPy、Microsoft GraphRAG 等主流 AI 框架广泛采用的开源 AI 网关，月均 PyPI 下载量高达 9700 万次。一连串漏洞的组合利用，使得攻击者可以在无需任何凭证的情况下远程控制 LiteLLM 服务器，并顺手拿走上面配置的所有 AI 服务商 API 密钥。
这不仅仅是又一个安全漏洞。这是 AI 基础设施的 Heartbleed 时刻。
漏洞链：从 MCP 测试端点到 CVSS 10.0
LiteLLM 是一个开源 Python 代理服务器，由 BerriAI 开发维护。它的核心价值主张很简单：提供一个统一的 OpenAI 兼容 API，背后对接 100 多个大语言模型提供商——OpenAI、Anthropic、Google Vertex AI、Azure、Cohere 等等。企业用它将所有 AI 请求集中路由、统一鉴权、控制成本和记录日志。
问题出在 LiteLLM 为支持 Model Context Protocol（MCP）而引入的两个测试端点：POST /mcp-rest/test/connection 和 POST /mcp-rest/test/tools/list。
这两个端点的设计初衷是让管理员在保存 MCP 服务器配置之前先测试连接。请求体中包含 command、args 和 env 三个字段，LiteLLM 会原样将其传递给子进程调用。关键问题在于：没有命令白名单、没有管理员角色检查、没有任何沙箱隔离。任何一个持有 LiteLLM 代理 API 密钥的用户——在大多数企业中，这种密钥会分发给整个开发团队——都可以提交任意可执行文件路径和参数，让代理服务器以自身权限执行。
这本身已经是一个 CVSS 8.7 的命令注入漏洞（CVE-2026-42271）。但真正的灾难来自于 Horizon3.ai 研究人员的发现：将 CVE-2026-42271 与 CVE-2026-48710（又称 BadHost）组合利用。
BadHost 是 Starlette 这个 Python ASGI 框架中的一个 Host 头认证绕过漏洞。Starlette 正是 LiteLLM HTTP 层的底层框架。在 1.0.1 之前的版本中，Starlette 不会验证 HTTP Host 头，而是直接将其用于 URL 重建。通过构造一个恶意的 Host 头，攻击者可以让认证中间件的路径匹配逻辑完全失效——从而绕过所有认证检查。
组合利用的效果：攻击者发送一个伪造 Host 头的 HTTP 请求，绕过了 Starlette 的认证中间件，然后将恶意命令通过 MCP 测试端点注入，Litellm 服务器以代理进程权限执行该命令。零凭证、零前置访问、完全的远程代码执行。Horizon3.ai 验证了完整攻击链，组合 CVSS 评分达到最高的 10.0 分。
Obsidian Security 随后在 6 月 11 日披露了另一条攻击链，将 CVE-2026-47101（认证绕过，低权限用户可生成通配符 API 密钥）、CVE-2026-47102（权限提升，可自行将角色修改为 proxy_admin）和 CVE-2026-40217（沙箱逃逸，通过 exec() 的 __builtins__ 注入实现任意代码执行）串联成一条完整的提权路径，评分 CVSS 9.9。这条链的可怕之处在于，它从一个每个 LiteLLM 部署都默认拥有的低权限内部账户出发，三步就到 root。
攻击者拿到的不是一台服务器，而是一把万能钥匙
理解这个漏洞的真正危害，需要理解 LiteLLM 在 AI 基础设施中的结构性位置。
LiteLLM 是一个集中式的 LLM API 代理。在生产环境中，一个典型的 LiteLLM 部署持有它路由到的每一个模型提供商的 API 密钥——OpenAI、Anthropic、Google、Azure、Bedrock、Cohere。它还持有数据库凭证（用于记录使用日志）、团队和用户的访问控制配置，以及网络层面对 AI Agent 框架、RAG 管道、向量数据库的访问权限。
攻击者一旦拿下 LiteLLM 实例，获得的远不止一台服务器的 Shell：
- 所有已配置的 AI 提供商 API 密钥：攻击者可以用企业的 OpenAI/Anthropic 等账户疯狂调用模型，产生的账单由受害者承担，同时还能窃取所有流经代理的提示词和模型回复。
- 环境变量和凭据文件：容器启动时注入的密钥、挂载的凭据文件、SSH 密钥、云服务商（AWS/GCP/Azure）凭证。
- 数据库内容：LiteLLM 的 PostgreSQL 数据库中存储着所有虚拟密钥、团队绑定、消费记录。在某些部署中，由于默认使用数据库超级用户权限，攻击者可以读取数据库中的所有表。
- 横向移动跳板：在 Kubernetes 部署中，如果代理进程的 Service Account 拥有集群范围的权限，攻击面将扩展到整个集群的控制平面。
Horizon3.ai 观察到，野外利用行为包括安装 Web Shell 以实现持久化访问、从环境变量和配置文件中收割凭据，以及在 Kubernetes 环境中尝试使用被入侵容器可访问的 Service Account Token 进行横向移动。
Cloud Security Alliance 在其研究报告中一针见血地指出：LiteLLM 的网关模式创造了"集中的凭据攻击面"。这句话值得反复咀嚼——它不是被攻击了，而是被设计成了一个理想的攻击目标。
CISA 的警告与全球的沉默
2026 年 5 月 8 日，LiteLLM 发布了 1.83.7 版本，将 MCP 测试端点限制为 PROXY_ADMIN 角色，并将 Starlette 依赖更新至 1.0.1。但补丁发布后的五周内，攻击者迅速完成了武器的工程化。
6 月 8 日，美国网络安全与基础设施安全局（CISA）确认 CVE-2026-42271 正在被野外活跃利用，将其正式纳入已知被利用漏洞（KEV）目录。依据《约束性操作指令》（BOD）22-01，联邦民事行政部门被要求在 6 月 22 日之前完成修补——从列入 KEV 到截止日期，只有两周。
但 BOD 22-01 的强制力止步于美国联邦政府。对于全球数以万计的 LiteLLM 企业部署者，CISA 的 KEV 列入不过是一则安全新闻，而非一个必须立即响应的作战指令。
更令人不安的是，这已经是 LiteLLM 在一个季度内第二次成为重大安全事件的主角。2026 年 3 月，一个名为 TeamPCP 的威胁行为者通过入侵 Trivy 容器安全扫描器的 GitHub Actions，然后横向窃取 LiteLLM 的 PyPI 发布令牌，在 PyPI 上发布了两个恶意版本的 LiteLLM（v1.82.7 和 v1.82.8）。恶意载荷包含三阶段攻击：凭证收割、Kubernetes 横向移动和持久化 systemd 后门。尽管 PyPI 在大约 40 分钟内就隔离了这两个恶意包，但在那段时间内，Microsoft GraphRAG、Google ADK、DSPy、CrewAI 和 OpenHands 等主流框架都可能作为传递依赖拉取了恶意版本。
Datadog Security Labs 随后将此次攻击与 TeamPCP 的更大规模供应链攻击活动联系起来，该活动同时瞄准了 Trivy、Checkmarx KICS 以及 npm 包和 OpenVSX 扩展。
这不是 LiteLLM 的问题，这是 AI 供应链安全的问题
把以上所有事件放在一起看，一个清晰的模式浮现出来：AI 行业的精力和资金大量集中在模型训练和算力基建上，而连接这一切的"管道"——开源 AI 中间件——却处于严重的安全投资不足状态。
LiteLLM 的 GitHub 仓库有超过 50,000 颗星星，月均 PyPI 下载量 9700 万次，被整合进了几乎所有主流的 AI Agent 框架。但它的安全实践——f-string SQL 查询、无白名单的子进程调用、缺失 __builtins__ 的 exec() 沙箱（这是自 2009 年以来就众所周知的 Python 陷阱）——暴露了快速成长的开源项目在安全审计上的历史欠账。
Cloud Security Alliance 在其 MAESTRO 框架分析中指出，LiteLLM 漏洞同时触及基础设施安全层（Layer 1）和 AI 模型与 API 安全层（Layer 2）。在基础设施层，MCP 测试端点缺少授权控制，是对最小权限原则的根本性违背。在模型与 API 层，网关作为所有 LLM API 流量的中介，一个被入侵的代理可以拦截、篡改或窃取流经它的每一个 AI 工作负载的请求和响应。
Starlette BadHost 漏洞（CVE-2026-48710）的影响范围更超出 LiteLLM 本身。比利时网络安全中心警告称，该漏洞影响"大量依赖 Starlette 的 Python AI 基础设施"，包括 FastAPI 服务、vLLM 推理服务器、MCP 服务器框架、Agent 运行环境和评估仪表板。这意味着即使你的组织不使用 LiteLLM，任何基于 Starlette 框架构建的 AI 服务都可能面临认证绕过的风险。
把 LiteLLM 事件称为 AI 基础设施的 Heartbleed 时刻，不是修辞上的夸张。2014 年的 Heartbleed 之所以成为标志性事件，不是因为它是最严重的漏洞，而是因为它暴露了一个被整个行业系统性忽视的关键依赖层。OpenSSL 支撑着互联网的加密基础设施，但它的维护者只有寥寥数人，预算微乎其微。同样地，LiteLLM 今天支撑着生成式 AI 的连接基础设施，但其安全投入与它承载的风险完全不成比例。
该做什么——以及为什么这很难
对于正在运行 LiteLLM 的组织，行动清单是明确的：升级至 v1.83.14 以上版本，升级 Starlette 至 v1.0.1 以上，轮换代理曾访问过的所有凭据——包括每一个 LLM 提供商的 API 密钥、数据库密码、主密钥、SSH 密钥和云凭据。
如果立即升级在操作上不可行，最高优先级的临时缓解措施是将 LiteLLM 代理从公共互联网上撤下，限制网络可达范围。同时审计代理 API 密钥的分发情况，撤销不再需要的密钥。
但这些措施对应的是表面的问题。更深层的问题在于：AI 安全治理项目需要建立对 AI 中间件组件的明确所有权、补丁管理义务和安全审查要求。一个 AI 网关承载的信任级别，应该获得与身份和访问管理系统相当的安全审慎程度。采购和部署审批流程应评估 AI 中间件供应商的安全开发生命周期实践、漏洞披露流程和响应及时性。
LiteLLM 已聘请 Veria Labs 进行代理审计，启动了漏洞赏金计划（500–3,000 美元），并承诺在 5 个工作日内响应安全通告。CrewAI 甚至发布了完全解耦 LiteLLM 的移除指南。这些是积极信号，但远远不够。
因为比 LiteLLM 本身的漏洞更令人不安的，是整个 AI 供应链安全意识的普遍缺失。行业花了几千亿美元训练模型和建设算力，但用来连接这一切的管道——开源 AI 网关、中间件和代理框架——却有一个 CVSS 10.0 的漏洞正在野外被利用。而且这不是唯一的一个，也不是最后一个。
Heartbleed 之后，互联网行业建立了 Core Infrastructure Initiative，系统性改善了关键开源项目的安全状况。AI 行业需要的，是一场同等力度的觉醒。
