al-ice.ai

vLLM — SSRF protection bypass via parser differential (CVE-2026-25960)

AI CVEs by al-ice.ai Editorial

AI relevance: vLLM powers model serving for thousands of production LLM deployments; a parser-differential SSRF bypass lets attackers reach internal services through the same MediaConnector that handles user-supplied URLs for multimodal inference.

  • CVE-2026-25960 bypasses the SSRF fix (CVE-2026-24779, patched in vLLM 0.15.1) in the load_from_url_async method, affecting vLLM 0.17.0.
  • Root cause: the validation layer uses urllib3.util.parse_url() while the HTTP client uses aiohttp + yarl — two URL parsers that handle backslash characters differently.
  • Supply https://httpbin.org\@evil.com/: urllib3 treats \@evil.com/ as part of the path (validates host = httpbin.org), but yarl interprets httpbin.org\ as userinfo and resolves host = evil.com.
  • The bypass allows an attacker to pass any arbitrary hostname through the allowlist check while the actual HTTP request goes elsewhere — full SSRF.
  • vLLM's MediaConnector handles URLs for image/audio/document inputs in multimodal pipelines, so this is reachable whenever a model processes user-controlled media URLs.
  • Impacts: internal metadata endpoints (cloud IAM), internal APIs, database admin consoles, and any service reachable from the vLLM host network.
  • Fixed in PR #34743 by aligning both parser layers. No CVSS assigned yet at NVD (GitHub rates it High).

Why it matters

  • Multi-stage fixes are common in security — this case shows how parser differentials between validation and execution layers silently reintroduce the same class of vulnerability.
  • vLLM is deployed behind public APIs serving untrusted user inputs (chatbots, document processors, multimodal agents), making SSRF a high-impact remote vector.
  • Any org running vLLM with multimodal support who applied the CVE-2026-24779 fix but hasn't updated past 0.17.0 is still exposed.

What to do

  • Upgrade vLLM to the version containing commit 6f3b204 (PR #34743).
  • Network-level mitigation: restrict outbound access from vLLM pods via Kubernetes NetworkPolicies or security groups — deny access to internal metadata IPs (169.254.169.254) and non-whitelisted CIDRs.
  • Audit URL handling in any custom connectors or plugins that sit between user input and HTTP clients — parser differentials are a recurring pattern.
  • Monitor for unusual outbound connections from vLLM instances, especially to internal IPs or unexpected external hosts.

Sources