CVE-2026-24779 — vLLM SSRF via Host Restriction Bypass
CVE: CVE-2026-24779
Product: vLLM
Affected Versions: vLLM versions prior to 0.14.1
Vulnerability Type: Server-Side Request Forgery (SSRF) — Host restriction bypass
Severity: High
CVSS v3.1 Score: 7.1 (High)
Attack Vector: Network
Attack Complexity: Low
Privileges Required: Low (ability to submit a media URL)
User Interaction: None
Impact: Internal network access, pod-to-pod attacks, sensitive data exposure, service disruption
Executive Summary
A high-severity SSRF vulnerability was identified in vLLM’s multimodal media handling logic. Due to inconsistent URL parsing during validation and execution, a crafted user-supplied URL can bypass host restrictions. This allows the vLLM service to make unintended outbound requests to internal or restricted network locations. The issue is fully resolved in vLLM version 0.14.1 and later.
Vulnerability Overview
The vulnerability exists in the MediaConnector logic responsible for loading user-supplied media from remote URLs. A host validation check was implemented to restrict outbound requests to approved destinations. However, the validation step relied on one URL parsing mechanism, while the actual HTTP request was executed using a different parser.
Because these parsers interpret certain URL characters differently—specifically backslashes (\)—a mismatch occurred between what was validated and what was ultimately requested. As a result, URLs that appeared safe during validation could resolve to internal or otherwise restricted hosts during execution.
This inconsistency created a condition where host-based restrictions could be bypassed.
Root Cause Analysis
The root cause was an inconsistency in URL parsing behavior:
- Validation phase: One parsing method interpreted backslashes as literal characters.
- Request phase: A different parsing method normalized backslashes into standard URL separators.
By abusing this difference, an attacker could construct a URL that passed validation checks but resolved to a different destination when the HTTP request was actually made.
Exploitation Scenario
The vulnerability can be exploited when:
- A vLLM deployment exposes multimodal functionality that accepts external media URLs.
- An attacker is able to supply a crafted URL as input.
Typical exploitation flow:
- A specially crafted URL containing backslashes is submitted as a media input.
- The URL passes host allowlist validation.
- During request execution, the URL is normalized differently and resolves to an internal address.
- The vLLM service performs the request from within the trusted environment.
Example Payloads
Note: These examples are for controlled testing and defensive validation only.
- Metadata access style payload:
http:\\169.254.169.254\latest\meta-data\ - Internal service targeting:
http:\\internal-service\:8080\health
Depending on runtime parsing behavior, these may be interpreted as valid internal HTTP requests.
Potential Impact
If successfully exploited, the following risks are introduced:
- Internal Network Access: Requests can be made to internal IP ranges not intended to be reachable.
- Cloud Metadata Exposure: Credentials or tokens may be retrieved from metadata services.
- Pod-to-Pod Attacks: In containerized environments, other services may be probed or accessed.
- Sensitive Data Leakage: Internal APIs may return confidential data.
- Denial of Service: Internal services may be overloaded or destabilized.
Exploit Availability
At the time of analysis:
- No fully weaponized public exploit kit is widely circulated.
- The attack technique is well understood and can be reproduced with basic knowledge of URL parsing differences.
- Exploitation is considered practically achievable, especially in environments without strict egress controls.
Detection and Monitoring Guidance
Log Sources to Monitor
- vLLM application logs (media load operations)
- Outbound HTTP proxy or gateway logs
- Container or host-level egress logs
- Cloud network flow logs
- Kubernetes network policy or CNI logs
Indicators of Exploitation
The following patterns should be treated as suspicious:
- Outbound requests to private IP ranges:
10.0.0.0/8172.16.0.0/12192.168.0.0/16169.254.169.254
- URLs containing backslashes (
\) instead of standard forward slashes - Media fetch requests immediately followed by unexpected outbound connections
- Repeated failed or unusual internal HTTP requests originating from vLLM pods or hosts
Detection Logic
Application Log Hunting
Search for media load events where the requested URL contains "\" characters
Proxy / Egress Log Filtering
Alert on outbound HTTP requests from vLLM processes to private IP ranges
Regex Pattern for URL Anomalies
http:\\\\|https:\\\\
These detections should be tuned to the specific logging format and environment.
MITRE Mapping
- CWE-918: Server-Side Request Forgery (SSRF)
- ATT&CK Techniques Enabled:
- Network Service Discovery
- Exploitation of Public-Facing Applications
- Lateral Movement (indirect)
Mitigation and Remediation
Primary Remediation
- Upgrade vLLM to version 0.14.1 or later
Official Patch / Upgrade Link:
https://github.com/vllm-project/vllm/commit/f46d576c54fb8aeec5fc70560e850bed38ef17d7
This update ensures consistent URL parsing is used for both validation and request execution, fully eliminating the bypass condition.
Additional Hardening
- Egress network restrictions to block access to internal and metadata IP ranges
- Input sanitization to reject URLs containing backslashes
- Strict allowlisting based on resolved IP addresses rather than hostnames
- Rate limiting on external media fetch operations
- Enhanced outbound request logging and alerting
Verification After Patch
After upgrading:
- Confirm vLLM version is 0.14.1 or newer
- Test known bypass payloads in a controlled environment to ensure they are rejected
- Validate that outbound requests to private IP ranges are blocked or logged
- Review logs for any historical indicators of compromise
Final Takeaway
This vulnerability represents a classic but high-impact SSRF condition caused by subtle parsing inconsistencies. While exploitation requires some understanding of URL behavior, the real-world risk is significant in cloud and containerized environments. Prompt patching combined with outbound traffic controls provides a complete and reliable mitigation.
