CVE-2026-25960: vLLM SSRF Vulnerability Bypass Issue

CVE-2026-25960 Overview

CVE-2026-25960 is a Server-Side Request Forgery (SSRF) vulnerability in vLLM, an inference and serving engine for large language models (LLMs). The flaw bypasses the SSRF protection introduced in version 0.15.1 for CVE-2026-24779. Inconsistent URL parsing between the validation layer and the HTTP client allows attackers to reach internal network resources. The validation uses urllib3.util.parse_url() while the load_from_url_async method issues requests through aiohttp, which parses URLs with the yarl library. This parser mismatch enables URL crafting that passes validation but resolves to a different host at request time. The issue affects vLLM version 0.17.0 [CWE-918].

Critical Impact
Unauthenticated network attackers can coerce vLLM servers into making arbitrary HTTP requests to internal services, exposing cloud metadata endpoints, internal APIs, and adjacent infrastructure.

Affected Products

vLLM version 0.17.0
vLLM deployments using load_from_url_async for remote resource loading
vLLM instances exposed to untrusted URL input from API clients

Discovery Timeline

2026-03-09 - CVE-2026-25960 published to NVD
2026-03-18 - Last updated in NVD database

Technical Details for CVE-2026-25960

Vulnerability Analysis

The vulnerability stems from a parser differential between two URL parsing libraries used in the same code path. The vLLM project addressed CVE-2026-24779 in release 0.15.1 by validating user-supplied URLs with urllib3.util.parse_url() and extracting the hostname for allowlist checks. However, load_from_url_async performs the actual HTTP fetch using aiohttp, which delegates URL parsing to the yarl library. The two parsers interpret authority components, percent-encoded characters, and embedded credentials differently. An attacker can construct a URL where urllib3 extracts a hostname that passes validation, while yarl resolves the request to an entirely different host. This class of bug is a documented SSRF bypass pattern affecting many web frameworks.

Root Cause

The root cause is inconsistent URL parsing behavior across the validation and request layers. Security decisions made on one parser's interpretation are enforced by a different parser at request time. The fix in pull request 34743 aligns parsing so the validated hostname matches the host actually contacted.

Attack Vector

Exploitation requires network access to a vulnerable vLLM endpoint accepting URL input. The attacker submits a crafted URL to a feature backed by load_from_url_async. The validation layer extracts a benign hostname, but aiohttp connects to an attacker-controlled or internal target. Common targets include cloud instance metadata services such as 169.254.169.254, internal admin APIs, and unauthenticated services on the loopback interface. Successful exploitation can yield cloud credentials, internal data, and lateral movement opportunities.

No public proof-of-concept code has been released. Technical details are available in the vLLM Security Advisory GHSA-v359-jj2v-j536 and the patch commit.

Detection Methods for CVE-2026-25960

Indicators of Compromise

Outbound HTTP requests from vLLM hosts to 169.254.169.254, 127.0.0.1, or RFC1918 ranges that do not match expected model storage endpoints.
Application logs showing load_from_url_async invocations where the requested URL contains unusual authority components, embedded @ characters, or non-ASCII hostname encodings.
Spikes in 4xx or 5xx responses for URL-loading endpoints, indicating parser probing.

Detection Strategies

Compare hostnames extracted by urllib3 against hostnames resolved by aiohttp or yarl at request time and alert on mismatches.
Enforce egress filtering on vLLM workloads and alert on connections to cloud metadata IPs or internal service ranges.
Inspect API request payloads for URLs containing credential-embedding, percent-encoded delimiters, or IPv6 representations that may exploit parser differentials.

Monitoring Recommendations

Forward vLLM application logs and process network telemetry to a centralized analytics platform for correlation.
Monitor cloud audit logs for metadata service queries originating from inference workload identities.
Track vLLM package versions across the fleet and alert on any host running version 0.17.0.

How to Mitigate CVE-2026-25960

Immediate Actions Required

Upgrade vLLM to a release containing commit 6f3b2047abd4a748e3db4a68543f8221358002c0 from pull request 34743.
Restrict network egress from vLLM hosts to only the model registries and storage endpoints required for operation.
Disable or gate any vLLM API surface that accepts arbitrary URLs from untrusted clients.

Patch Information

The vLLM maintainers fixed the parser differential in pull request 34743, merged as commit 6f3b2047abd4a748e3db4a68543f8221358002c0. Operators running version 0.17.0 should upgrade to the patched release. Refer to GitHub Security Advisory GHSA-v359-jj2v-j536 and the related GHSA-qh4c-xf7m-gxfc for advisory details.

Workarounds

Place vLLM behind a network policy that blocks access to cloud metadata IPs and internal subnets.
Terminate URL-loading requests at an authenticated proxy that revalidates and normalizes hostnames before forwarding.
Require authentication on vLLM endpoints and restrict URL inputs to a strict allowlist of trusted domains.

bash

# Configuration example
# Kubernetes NetworkPolicy denying egress to cloud metadata and RFC1918 ranges
# Apply to namespaces running vLLM workloads
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:
              - 169.254.169.254/32
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
EOF