🔴 【深度分析】严重安全漏洞：CVE-2026-48746

CVSS 评分: 严重（9.1）🔴　　状态: Analyzed　　发布时间: 2026-06-22

🔍 技术细节速览

字段 值
CVE ID CVE-2026-48746
CVSS 评分 9.1 🔴
严重程度 严重
CVSS 向量 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
CWE 分类 CWE-444
发布时间 2026-06-22
状态 Analyzed

好的，作为一名资深网络安全分析师，我将基于您提供的 NVD 漏洞数据，对 CVE-2026-48746 进行深度分析。

漏洞概述

CVE-2026-48746 是一个存在于 vLLM 项目中的严重安全漏洞。vLLM 是一个高性能的大型语言模型（LLM）推理和服务引擎。该漏洞源于 vLLM 对 ASGI Web 服务器及 Starlette 框架的信任机制存在缺陷，导致攻击者可以绕过 OpenAI API 的认证中间件（AuthenticationMiddleware）。成功利用此漏洞的攻击者，即使未提供配置的 VLLM_API_KEY 或 --api-key，也能未经授权地访问 vLLM 提供的 API 服务。

该漏洞的 CVSS 评分为 9.1（严重），攻击复杂度低，无需用户交互，且可远程利用，对机密性和可用性造成严重影响。

受影响组件与版本

  • 受影响组件: vLLM
  • 受影响版本: >= 0.3.0, < 0.22.0
  • 修复版本: 0.22.0

漏洞原理分析

该漏洞的核心问题在于 vLLM 的 API 认证机制与底层 ASGI Web 服务器（如 Uvicorn）及 Starlette 框架之间的交互存在不一致性。

  1. 信任关系: vLLM 的 AuthenticationMiddleware 依赖于 ASGI Web 服务器来正确解析和传递 HTTP 请求的路径信息。在标准的 HTTP 请求中，路径信息是明确的。然而，ASGI 规范允许 Web 服务器通过 root_path 等机制来修改或影响应用程序接收到的请求路径。

  2. CWE-444 本质: 该漏洞被归类为 CWE-444（HTTP 请求走私/路径不一致）。具体来说，攻击者可以构造一个特殊的 HTTP 请求，利用 ASGI Web 服务器和 Starlette 框架在解析请求路径时的细微差异，使得认证中间件无法正确识别需要保护的 API 端点。

  3. 绕过机制: 攻击者可能通过发送包含特殊编码、路径遍历（如 ../）或利用 root_path 配置的请求，使得请求的路径在到达 AuthenticationMiddleware 时被错误地解析。例如，攻击者可能将 /v1/chat/completions 伪装成 /some_public_endpoint/../v1/chat/completions。如果 Web 服务器和 Starlette 对此路径的处理方式不同，认证中间件可能认为这是一个无需认证的公共路径，从而放行请求，而实际请求却被路由到了需要认证的 API 端点。

  4. 技术细节: 根据参考链接（X41 安全报告），该漏洞与 Starlette 框架如何处理 ASGI 服务器提供的 root_path 有关。在某些配置或特定请求构造下，Starlette 的路径匹配逻辑可能被欺骗，导致认证中间件被绕过。具体的攻击向量需要深入分析 vLLM 0.22.0 之前的代码以及其依赖的 Starlette 版本。

影响评估

  • 严重性: 严重 (CVSS 9.1)
  • 攻击向量: 网络远程攻击，无需任何权限或用户交互。
  • 影响范围:
    • 机密性 (High): 攻击者可以未经授权访问 vLLM 服务，从而调用 LLM 推理接口。这可能导致模型本身、训练数据、用户查询和推理结果等敏感信息泄露。
    • 完整性 (None): 根据 CVSS 向量，该漏洞主要影响机密性和可用性，对数据完整性无直接影响。但攻击者可以滥用 API 进行恶意操作。
    • 可用性 (High): 攻击者可以大量调用 API，消耗计算资源，导致服务拒绝（DoS），影响正常用户的访问。
  • 业务风险: 对于部署了 vLLM 并依赖 API Key 进行访问控制的企业和组织，此漏洞意味着其安全防线形同虚设。攻击者可以完全控制 LLM 服务的使用权，进行数据窃取、模型滥用、服务破坏等恶意活动，造成严重的经济损失和声誉损害。

修复建议

  1. 立即升级: 最直接有效的修复措施是将 vLLM 升级到 0.22.0 或更高版本。该版本已修复此认证绕过漏洞。
  2. 临时缓解措施:
    • 网络隔离: 如果无法立即升级，应将 vLLM 服务部署在严格的网络隔离环境中，例如仅允许受信任的内部网络或 VPN 访问，避免直接暴露在公网。
    • 反向代理认证: 在 vLLM 前端部署一个反向代理（如 Nginx、HAProxy），并在代理层实现额外的认证和访问控制。确保只有通过代理认证的请求才能到达 vLLM 服务。这可以作为 vLLM 自身认证机制失效时的第二道防线。
    • 监控与告警: 加强针对 vLLM API 的访问日志监控，特别关注异常的请求模式、路径构造以及未携带 API Key 的请求，及时发现潜在的利用行为。
  3. 代码审查: 对于使用 vLLM 源码进行二次开发的团队，应仔细审查 AuthenticationMiddleware 的实现，特别是与 ASGI 服务器和 Starlette 框架交互的部分，确保路径解析逻辑的健壮性。

参考资料