CVE-2026-34753: vLLM SSRF Vulnerability

CVE-2026-34753 Overview

CVE-2026-34753 is a Server-Side Request Forgery (SSRF) vulnerability in vLLM, an inference and serving engine for large language models (LLMs). The vulnerability exists in the download_bytes_from_url function from versions 0.16.0 to before 0.19.0, allowing any actor who can control batch input JSON to make the vLLM batch runner issue arbitrary HTTP/HTTPS requests from the server without any URL validation or domain restrictions.

Critical Impact

Attackers can exploit this SSRF vulnerability to target internal services such as cloud metadata endpoints or internal HTTP APIs reachable from the vLLM host, potentially leading to information disclosure and unauthorized access to internal resources.

Affected Products

• vLLM versions 0.16.0 to before 0.19.0

Discovery Timeline

• 2026-04-06 - CVE CVE-2026-34753 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-34753

Vulnerability Analysis

This vulnerability is classified as CWE-918 (Server-Side Request Forgery). The flaw resides in the download_bytes_from_url function within the vLLM batch processing subsystem. When processing batch input JSON, the function accepts user-supplied URLs and fetches content from those URLs without implementing proper validation or domain restrictions.

The lack of URL validation means that an attacker with the ability to control batch input parameters can craft malicious requests that cause the vLLM server to make HTTP/HTTPS requests to arbitrary destinations. This is particularly dangerous in cloud environments where internal metadata services (such as AWS EC2 metadata at 169.254.169.254) can be queried to extract sensitive credentials and configuration data.

Root Cause

The root cause of this vulnerability is the absence of URL validation and domain allowlisting in the download_bytes_from_url function. The function directly processes user-supplied URLs from batch input JSON without checking whether the destination is an internal network address, localhost, or a restricted cloud metadata endpoint. This permissive design allows external attackers to pivot through the vLLM server to access resources that would otherwise be unreachable from outside the network.

Attack Vector

The attack vector is network-based and requires low-privileged access. An attacker must be able to submit batch processing requests to the vLLM server with controlled input JSON. By embedding a malicious URL in the batch input, the attacker can instruct the server to make requests to:

• Cloud metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/)
• Internal HTTP APIs not exposed to the internet
• Localhost services running on the vLLM host
• Other internal network resources

The attacker can then observe the server's response or behavior to extract sensitive information from these internal services. For detailed technical information about the exploitation mechanism, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-34753

Indicators of Compromise

• Unusual outbound HTTP/HTTPS requests from the vLLM server to internal IP ranges (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x)
• Requests targeting cloud metadata endpoints such as 169.254.169.254
• Batch processing jobs containing URLs pointing to internal services or localhost
• Unexpected network connections from the vLLM process to non-standard ports or internal hosts

Detection Strategies

• Monitor batch input JSON payloads for suspicious URL patterns including internal IP addresses, localhost references, and cloud metadata endpoints
• Implement network-level monitoring to detect outbound requests from vLLM servers to internal network ranges
• Configure web application firewalls to flag requests containing SSRF payload patterns
• Enable verbose logging for the vLLM batch runner to capture all URL fetch operations

Monitoring Recommendations

• Deploy network segmentation rules to restrict vLLM server outbound connectivity to only necessary external services
• Implement egress filtering to block requests to cloud metadata IP ranges from application servers
• Use SentinelOne Singularity to monitor for anomalous network behavior from vLLM processes
• Set up alerting for any batch jobs that reference internal network addresses or restricted domains

How to Mitigate CVE-2026-34753

Immediate Actions Required

• Upgrade vLLM to version 0.19.0 or later immediately
• Audit existing batch processing configurations for any suspicious or untrusted URL inputs
• Implement network-level controls to restrict outbound HTTP/HTTPS requests from vLLM servers
• If cloud-hosted, configure instance metadata service (IMDS) to require session tokens (IMDSv2 on AWS)

Patch Information

The vulnerability is fixed in vLLM version 0.19.0. Users should upgrade to this version or later to remediate the SSRF vulnerability. Review the GitHub Security Advisory for complete patch details and upgrade instructions.

Workarounds

• Implement a reverse proxy or web application firewall in front of the vLLM service to validate and sanitize incoming batch input URLs
• Deploy network egress rules to block outbound requests to internal IP ranges and cloud metadata endpoints from the vLLM host
• Restrict access to the vLLM batch processing endpoint to trusted users only through authentication and authorization controls
• If upgrading is not immediately possible, consider disabling the batch processing functionality until the patch can be applied

# Network-level mitigation: Block outbound requests to cloud metadata endpoints
# Example iptables rules to block common SSRF targets from the vLLM host
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -p tcp --dport 80 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -p tcp --dport 443 -j DROP