CVE-2026-25960: 
NixOS vulnerability analysis and mitigation

CVE-2026-25960 is an SSRF protection bypass vulnerability in vLLM, an inference and serving engine for large language models. It affects vLLM versions >= 0.15.1 and < 0.17.0, and bypasses the SSRF fix previously introduced in version 0.15.1 for CVE-2026-24779 (GHSA-qh4c-xf7m-gxfc). The vulnerability was published on March 9, 2026, and is patched in version 0.17.0. The GitHub Security Advisory assigns a CVSS v3.1 score of 5.4 (Moderate), while Feedly's threat intelligence estimates a higher score of 9.8 (Critical) based on network-accessible, no-authentication-required exploitation potential (Github Advisory, vLLM Advisory).

The root cause is an inconsistent URL parsing behavior (CWE-918, CWE-474) between the validation layer and the HTTP client in vLLM's load_from_url_async method (file: vllm/connections.py). The SSRF validation uses urllib3.util.parse_url(), which URL-encodes backslashes (\) as %5C and treats \@evil.com/ as part of the path — leaving the parsed host as the allowlisted domain. However, the actual HTTP request is made via aiohttp, which uses the yarl library internally; yarl interprets the backslash as part of the userinfo component and treats @ as the userinfo/host separator, resolving the effective host as the attacker-controlled domain. A crafted URL such as https://httpbin.org\@evil.com/ passes validation (host seen as httpbin.org) but causes the actual request to be sent to evil.com. The fix (PR #34743, commit 6f3b204) resolves this by passing the urllib3-normalized URL (url_spec.url) to the HTTP client instead of the raw user-provided string (vLLM Advisory, Fix PR).

Successful exploitation allows an attacker to cause the vLLM server to make HTTP requests to arbitrary internal or external network resources, bypassing the hostname allowlist. This enables access to sensitive internal services (e.g., cloud metadata endpoints at 169.254.169.254, internal APIs, or other pods in containerized environments like llm-d), internal network scanning, and potential lateral movement to attack internal infrastructure. Confidentiality is impacted through exposure of internal data; availability may be impacted by interaction with internal management endpoints that could destabilize services (vLLM Advisory, Github Advisory).

A proof-of-concept exploit scenario is publicly documented in the GitHub Security Advisory, including a concrete malicious URL payload and step-by-step explanation of the bypass mechanism (vLLM Advisory). There is no evidence of active in-the-wild exploitation at this time. The EPSS score is approximately 0.028% (8th percentile), indicating a low current probability of exploitation in the next 30 days (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low privileges (authenticated API access), reducing the attack surface compared to fully unauthenticated vulnerabilities.

1. Identify target: Locate a vLLM deployment running version >= 0.15.1 and < 0.17.0 that exposes a multimodal API endpoint accepting user-supplied URLs (e.g., for image, audio, or video input).
2. Craft malicious URL: Construct a URL using the backslash-@ bypass pattern, where the allowlisted hostname appears before the backslash and the attacker-controlled target follows the @: https://allowlisted-domain.com\@internal-target.com/sensitive-path.
3. Submit URL to vLLM: Send an API request to the vLLM multimodal endpoint (e.g., a chat completion request with an image URL parameter) supplying the crafted malicious URL.
4. Bypass validation: The urllib3.util.parse_url() validation layer parses the host as allowlisted-domain.com and passes the allowlist check.
5. Trigger SSRF: The aiohttp/yarl HTTP client interprets the backslash as a userinfo separator, resolves the effective host as internal-target.com, and makes the HTTP request to the attacker-chosen internal resource.
6. Exfiltrate data: The response from the internal resource (e.g., cloud metadata, internal API responses) is returned to or observable by the attacker via the vLLM response or error messages (vLLM Advisory).

• Network: Outbound HTTP requests from the vLLM server process to unexpected internal IP ranges (e.g., 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or to external hosts not matching the configured allowed_media_domains.
• Network: HTTP requests originating from the vLLM host to cloud metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/) or internal Kubernetes/container orchestration APIs.
• Logs: vLLM application logs showing URL fetch attempts containing backslash characters (\) or %5C sequences in URL parameters, particularly in multimodal media fetch operations.
• Logs: Unexpected HTTP 200 responses from internal services logged by vLLM when processing user-supplied media URLs.
• Process: The vLLM Python process initiating connections to hosts not present in the configured media domain allowlist.

Upgrade vLLM to version 0.17.0 or later, which contains the fix (commit 6f3b2047abd4a748e3db4a68543f8221358002c0, PR #34743) that passes the urllib3-normalized URL to the HTTP client, ensuring consistent URL parsing between validation and request layers (Fix PR, Fix Commit). As a network-level workaround, implement egress firewall rules or network policies to restrict outbound HTTP requests from the vLLM process to only necessary destinations, blocking access to sensitive ranges such as 169.254.0.0/16, 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. In containerized environments (e.g., Kubernetes), apply NetworkPolicy resources to limit pod-level egress (Github Advisory).

The vulnerability was reported by security researchers RacerZ-fighting and Fushuling, coordinated by russellb (Red Hat), and remediated by Isotr0py and DarkLight1337 from the vLLM project (vLLM Advisory). A Medium article titled "vLLM in Production: A Security Hardening Guide for Enterprise Deployments" referenced this vulnerability in the context of enterprise security guidance for vLLM deployments. The vulnerability received coverage across standard CVE tracking platforms and security databases shortly after disclosure, with no notable controversy or widespread social media discussion identified.