vLLM has SSRF Protection Bypass
Medium5.4CVE-2026-25960 · Published Mar 9, 2026 · updated Jul 17, 2026
## Summary The SSRF protection fix for https://github.com/vllm-project/vllm/security/advisories/GHSA-qh4c-xf7m-gxfc can be bypassed in the `load_from_url_async` method due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client. ## Affected Component - **File**: `vllm/connections.py` - **Function**: `load_from_url_async` ## Vulnerability Details ### Root Cause The SSRF [fix](https://github.com/vllm-project/vllm/pull/32746) uses `urllib3.util.parse_url()` to validate and extract the hostname from user-provided URLs. However, `load_from_url_async` uses `aiohttp` for making the actual HTTP requests, and `aiohttp` internally uses the `yarl` library for URL parsing. These two URL parsers handle backslash characters (`\`) differently: | Parser | Input URL | Parsed Host | Parsed Path | Behavior | |--------|-----------|-------------|-------------|----------| | `urllib3.parse_url()` | `https://httpbin.org\@evil.com/` | `httpbin.org` | `/%5C@evil.com/` | URL-encodes `\` as `%5C`, treats `\@evil.com/` as part of the path | | `yarl` (via aiohttp) | `https://httpbin.org\@evil.com/` | `evil.com` | `/` | Treats `\` as part of userinfo (`user: httpbin.o...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| vllm PyPI | >= 0.15.1, < 0.17.0 | 0.17.0 |
Details and references
## Summary The SSRF protection fix for https://github.com/vllm-project/vllm/security/advisories/GHSA-qh4c-xf7m-gxfc can be bypassed in the `load_from_url_async` method due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client. ## Affected Component - **File**: `vllm/connections.py` - **Function**: `load_from_url_async` ## Vulnerability Details ### Root Cause The SSRF [fix](https://github.com/vllm-project/vllm/pull/32746) uses `urllib3.util.parse_url()` to validate and extract the hostname from user-provided URLs. However, `load_from_url_async` uses `aiohttp` for making the actual HTTP requests, and `aiohttp` internally uses the `yarl` library for URL parsing. These two URL parsers handle backslash characters (`\`) differently: | Parser | Input URL | Parsed Host | Parsed Path | Behavior | |--------|-----------|-------------|-------------|----------| | `urllib3.parse_url()` | `https://httpbin.org\@evil.com/` | `httpbin.org` | `/%5C@evil.com/` | URL-encodes `\` as `%5C`, treats `\@evil.com/` as part of the path | | `yarl` (via aiohttp) | `https://httpbin.org\@evil.com/` | `evil.com` | `/` | Treats `\` as part of userinfo (`user: httpbin.org\`), the `@` acts as the userinfo/host separator | ### Attack Scenario ```python # Attacker provides this URL malicious_url = "https://httpbin.org\\@evil.com/" # 1. Validation layer (urllib3.parse_url) parsed = urllib3.util.parse_url(malicious_url) # parsed.host == "httpbin.org" ✅ Passes validation # 2. Actual request (aiohttp with yarl) async with aiohttp.ClientSession() as session: async with session.get(malicious_url) as response: # Request actually goes to evil.com! ❌ Bypass! ``` ### Why This Happens 1. **yarl**: Interprets `httpbin.org\` as the userinfo component, and `@` as the userinfo/host separator, so the URL is parsed as `user=httpbin.org\`, `host=evil.com`, `path=/` 2. **urllib3**: URL-encodes the backslash as `%5C`, so `\@evil.com/` becomes `/%5C@evil.com/` which is treated as part of the path, leaving `host=httpbin.org` This inconsistency allows an attacker to: - Bypass the hostname allowlist check - Access arbitrary internal/external services - Perform full SSRF attacks ## Fixes - https://github.com/vllm-project/vllm/pull/34743
- CVSS 3.1
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L
- Severity from
- GitHub (reviewed advisory)
- Weakness
- CWE-918
- Also known as
- CVE-2026-25960, PYSEC-2026-3411
- github.com/vllm-project/vllm/security/advisories/GHSA-qh4c-xf7m-gxfc
- github.com/vllm-project/vllm/security/advisories/GHSA-v359-jj2v-j536
- nvd.nist.gov/vuln/detail/CVE-2026-25960
- github.com/vllm-project/vllm/pull/34743
- github.com/vllm-project/vllm/commit/6f3b2047abd4a748e3db4a68543f8221358002c0
- access.redhat.com/errata/RHSA-2026:24977
- access.redhat.com/security/cve/CVE-2026-25960
- bugzilla.redhat.com/show_bug.cgi?id=2445892
- github.com/advisories/GHSA-v359-jj2v-j536
- github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-3411.yaml
- github.com/vllm-project/vllm
- pypi.org/project/vllm
- security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-25960.json
More vLLM advisories
All vLLM| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Apr 3 | vLLM: Denial of Service via Unbounded Frame Count in video/jpeg Base64 Processing | Medium6.5 | 0.19.0 |
| Apr 3 | vLLM: Server-Side Request Forgery (SSRF) in `download_bytes_from_url ` | Medium5.4 | 0.19.0 |
| Apr 3 | vLLM: Unauthenticated OOM Denial of Service via Unbounded `n` Parameter in OpenAI API Server | Medium6.5 | 0.19.0 |
| Mar 27 | vLLM has Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out | High8.8 | 0.18.0 |
| Feb 2 | vLLM has RCE In Video Processing | Critical9.8 | 0.14.1 |
| Jan 28 | vLLM vulnerable to Server-Side Request Forgery (SSRF) through MediaConnector | High7.1 | 0.14.1 |