CVE-2026-24779: vLLM SSRF Vulnerability

CVE-2026-24779 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in the vLLM project, an inference and serving engine for large language models (LLMs). The vulnerability exists in the MediaConnector class within vLLM's multimodal feature set. The load_from_url and load_from_url_async methods process media from user-supplied URLs but use different Python parsing libraries when restricting target hosts. These parsing libraries interpret backslashes differently, allowing attackers to bypass hostname restrictions and force the vLLM server to make arbitrary requests to internal network resources.

Critical Impact

Attackers can exploit this SSRF vulnerability to scan internal networks, interact with internal pods in containerized environments, access sensitive data, and potentially cause denial of service by manipulating internal management endpoints.

Affected Products

• vLLM versions prior to 0.14.1
• vLLM deployments with multimodal features enabled
• Containerized vLLM deployments (including llm-d environments)

Discovery Timeline

• 2026-01-27 - CVE CVE-2026-24779 published to NVD
• 2026-01-29 - Last updated in NVD database

Technical Details for CVE-2026-24779

Vulnerability Analysis

This SSRF vulnerability stems from inconsistent URL parsing behavior between different Python libraries used within vLLM's MediaConnector class. When the application attempts to validate and restrict which hosts can be accessed via user-supplied URLs, it uses one parsing library for validation but a different library for the actual HTTP request. The critical issue lies in how these libraries handle backslash characters (\) in URLs—one library may normalize or ignore them while the other interprets them differently, creating a parsing differential that can be exploited.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery), which occurs when a web application fetches remote resources based on user-supplied input without properly validating the destination. In this case, an attacker can craft a malicious URL that passes the hostname validation check but ultimately resolves to an internal network address.

Root Cause

The root cause is the use of two different URL parsing libraries with inconsistent backslash handling for hostname restriction enforcement. When validating user-supplied URLs, the application uses one parser to check if the target host is allowed, but the actual HTTP client uses a different parser that interprets backslashes differently. This parsing differential allows specially crafted URLs to bypass the allowlist/blocklist checks while still reaching internal hosts.

Attack Vector

An attacker can exploit this vulnerability by submitting a specially crafted URL containing backslash characters to the vLLM multimodal endpoints. The URL is designed to:

1. Pass through the hostname validation check by appearing to target an allowed external host
2. Be interpreted by the HTTP client as targeting an internal resource due to different backslash parsing

In containerized environments like llm-d, this attack is particularly dangerous. A compromised vLLM pod could be leveraged to:

• Scan the internal Kubernetes network for services and pods
• Interact with internal management endpoints (e.g., falsely reporting KV cache state)
• Access sensitive metadata services or configuration endpoints
• Cause denial of service by disrupting internal service communications

For detailed technical information about the vulnerability mechanism, see the GitHub Security Advisory GHSA-qh4c-xf7m-gxfc.

Detection Methods for CVE-2026-24779

Indicators of Compromise

• Unusual outbound HTTP requests from vLLM pods to internal IP addresses or services
• URL patterns containing backslash characters (\) in multimodal media loading requests
• Unexpected connections to internal metadata services (e.g., 169.254.169.254 on cloud platforms)
• Anomalous network traffic from vLLM containers to internal Kubernetes service endpoints

Detection Strategies

• Monitor vLLM application logs for URL parsing errors or unusual media loading requests
• Implement network monitoring to detect connections from vLLM pods to unexpected internal destinations
• Deploy Web Application Firewall (WAF) rules to detect URLs with suspicious backslash patterns
• Use SentinelOne Singularity Platform to monitor for SSRF attack patterns and anomalous network behavior

Monitoring Recommendations

• Enable verbose logging for the MediaConnector class and multimodal endpoints
• Configure network policies to restrict egress traffic from vLLM pods to known-good destinations
• Set up alerts for any internal network scanning activity originating from vLLM containers
• Monitor for attempts to access cloud metadata endpoints or internal management APIs

How to Mitigate CVE-2026-24779

Immediate Actions Required

• Upgrade vLLM to version 0.14.1 or later immediately
• Review and restrict network egress policies for vLLM deployments
• Implement network segmentation to limit internal access from vLLM pods
• Audit logs for any signs of exploitation attempts using backslash-containing URLs

Patch Information

The vLLM project has released version 0.14.1 which contains a fix for this SSRF vulnerability. The patch ensures consistent URL parsing by normalizing backslash handling before both validation and request execution.

For technical details about the fix, refer to:

• GitHub Pull Request #32746
• GitHub Commit f46d576c54fb8aeec5fc70560e850bed38ef17d7

Workarounds

• Disable multimodal features if not required for your use case
• Implement strict network egress controls using Kubernetes NetworkPolicy or cloud security groups
• Deploy a reverse proxy that validates and normalizes URLs before forwarding to vLLM
• Use application-level URL validation that rejects any URLs containing backslash characters

# Example Kubernetes NetworkPolicy to restrict vLLM pod egress
# Apply this to limit outbound connections from vLLM pods
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: vllm-egress-restrict
spec:
  podSelector:
    matchLabels:
      app: vllm
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16
        - 169.254.169.254/32
EOF