What is the CVSS score of CVE-2026-48746?

CVE-2026-48746 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H. EPSS exploitation probability: 0.7%.

Which versions of vLLM are affected by CVE-2026-48746?

A critical authentication bypass in vLLM 0.3.0-0.21.x enables unauthorized users to access proprietary language model APIs without credentials through Host header manipulation.. A patch is available.

How to fix or mitigate CVE-2026-48746?

Within 24 hours: Identify and catalog all vLLM deployments running versions 0.3.0-0.21.x and assess whether they serve external traffic. Within 7 days: Upgrade all affected instances to vLLM 0.22.0 or later. Within 30 days: Review prior 30 days of API logs for unauthorized access patterns, confirm patch completion across all infrastructure, and implement host header validation monitoring.

vLLM CVE-2026-48746

CRITICAL

HTTP Request/Response Smuggling (CWE-444)

2026-06-16 https://github.com/vllm-project/vllm

GHSA-94f4-hr76-p5j6

Nginx Authentication Bypass Request Smuggling

9.1

CVSS 3.1 · Vendor: https://github.com/vllm-project/vllm

Severity by source

Vendor (https://github.com/vllm-project/vllm) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

vuln.today AI

9.1 CRITICAL

Single unauthenticated HTTP request over the network bypasses the API key; full model access and GPU-cost availability impact, but no integrity change to the server, so I:N.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N

Red Hat

9.1 HIGH

qualitative

Primary rating from Vendor (https://github.com/vllm-project/vllm).

CVSS VectorVendor: https://github.com/vllm-project/vllm

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 16, 2026 - 18:22 vuln.today

Analysis Generated

Jun 16, 2026 - 18:22 vuln.today

CVE Published

Jun 16, 2026 - 17:36 github-advisory

CRITICAL 9.1

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

2 pypi packages depend on vllm (2 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.3.0.

DescriptionCVE.org

Summary

A vulnerability in ASGI web servers and starlette's trust on those web servers enables an authentication bypass of the OpenAI API AuthenticationMiddleware, which was discovered during @x41sec's source code audit. It allows to use the API without providing the configured VLLM_API_KEY or --api-key.

Details

In https://github.com/vllm-project/vllm/blob/v0.14.0/vllm/entrypoints/openai/api_server.py#L689-L692 the url_path is taken from the URL, which is reconstructed by _starlette_ based on the request scope.

from starlette.datastructures import URL, Headers, MutableHeaders, State
# ...

url_path = URL(scope=scope).path.removeprefix(root_path)
headers = Headers(scope=scope)
if url_path.startswith("/v1") and not self.verify_token(headers):
    response = JSONResponse(content={"error": "Unauthorized"}, status_code=401)
    return response(scope, receive, send)
return self.app(scope, receive, send)

The request scope includes the request's Host: header and reconstructs the URL as shown below:

f"{scheme}://{host_header}{path}"

Neither starlette nor any of the ASGI servers (including uvicorn, which vllm uses) properly filter the Host: header for invalid characters. This allows an attacker to include special URL characters such as / or ? in the Host: header and thereby control the reconstructed URL and it's .path attribute.

FastAPI/starlette's routing uses the HTTP path and does not depend on the parsed url.path attribute, allowing attackers to reach an endpoint via a certain path while providing a different value in the .path.

Impact

Instances of vllm that use an API Key for the OpenAI API and expose the API to attackers.
Instances behind an RFC-conforming web server (such as nginx) are not affected.

Articles & Coverage 2

News 4 New Nginx Vulnerabilities - 1 Critical, 3 High Severity Jun 17, 2026 News Critical Authentication Bypass in Nginx/vLLM OpenAI API - CVE-2026-48746 Jun 16, 2026

AnalysisAI

Authentication bypass in vLLM versions 0.3.0 through 0.21.x allows remote unauthenticated attackers to reach OpenAI-compatible API endpoints without supplying the configured VLLM_API_KEY by injecting URL-special characters into the HTTP Host header. The flaw stems from vLLM's AuthenticationMiddleware reconstructing the request URL via starlette's URL(scope) - which trusts an unsanitized Host value - while FastAPI routing uses the raw HTTP path, producing a mismatch the attacker controls. No public exploit identified at time of analysis, but x41-dsec disclosed full technical details and a vendor-released patch is available in 0.22.0.

Technical ContextAI

vLLM is a high-throughput LLM inference and serving engine that exposes an OpenAI-compatible REST API through a FastAPI/Starlette application served by uvicorn (an ASGI server). The vulnerable AuthenticationMiddleware in vllm/entrypoints/openai/api_server.py guards any path starting with /v1, but derives that path by calling starlette.datastructures.URL(scope=scope).path, which rebuilds a URL string as scheme://host_header/path and then re-parses it. Because neither uvicorn nor any other listed ASGI server filters invalid characters out of the Host header, an attacker who places '/' or '?' inside Host causes the parsed .path to differ from the raw scope['path'] that Starlette's router actually uses for dispatch - a classic CWE-444 (Inconsistent Interpretation of HTTP Requests / request smuggling) desynchronization between two HTTP parsers in the same stack. The fix (PR #43426) simply reads scope['path'] directly, eliminating the second parser.

RemediationAI

Vendor-released patch: upgrade vllm to 0.22.0 or later, which replaces the URL(scope).path reconstruction with a direct read of scope['path'] (see https://github.com/vllm-project/vllm/pull/43426 and advisory https://github.com/vllm-project/vllm/security/advisories/GHSA-94f4-hr76-p5j6). Where immediate upgrade is not possible, place vLLM behind an RFC-conforming reverse proxy such as nginx that strictly validates the Host header and rejects requests containing '/', '?', '#' or other URL-special characters - the vendor confirms this fully mitigates the bypass, with the trade-off of an added network hop and the operational burden of TLS termination and proxy configuration. Network-level controls such as restricting the uvicorn listener to localhost or an internal VPC and enforcing authentication at an upstream API gateway are also effective; relying solely on the application-layer API key without a sanitizing proxy should be considered unsafe for any version below 0.22.0.