CVE-2026-48746: Vllm Authentication Bypass Vulnerability

CVE-2026-48746 Overview

CVE-2026-48746 is an authentication bypass vulnerability in vLLM, an inference and serving engine for large language models (LLMs). The flaw affects versions 0.3.0 through 0.21.x and stems from how starlette's AuthenticationMiddleware trusts requests forwarded by upstream ASGI web servers. Attackers can invoke the OpenAI-compatible API without supplying the configured VLLM_API_KEY or --api-key value. The issue is tracked under [CWE-444] (Inconsistent Interpretation of HTTP Requests) and was fixed in vLLM 0.22.0.

Critical Impact
Unauthenticated network attackers can access protected vLLM inference endpoints, query private models, and exhaust GPU resources without supplying API credentials.

Affected Products

vLLM versions 0.3.0 through 0.21.x
Deployments using starlette's AuthenticationMiddleware with the OpenAI-compatible API server
vLLM instances configured with VLLM_API_KEY or --api-key as the sole access control

Discovery Timeline

2026-06-22 - CVE-2026-48746 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-48746

Vulnerability Analysis

The vulnerability resides in the interaction between vLLM's OpenAI-compatible API server, starlette's AuthenticationMiddleware, and the upstream ASGI web server hosting the application. Starlette's middleware assumes the ASGI server normalizes and validates inbound HTTP requests before they reach application logic. Attackers craft requests that the ASGI layer forwards in a form the middleware does not properly inspect for the API key. The middleware then permits the request to reach protected route handlers as if it had been authenticated.

The result is a complete bypass of the API key check that vLLM operators configure through VLLM_API_KEY environment variables or the --api-key command-line flag. Once past the middleware, requests can invoke completion, chat, and embedding endpoints exposed by the server.

Root Cause

The root cause is misplaced trust in ASGI request normalization. Starlette's AuthenticationMiddleware does not independently enforce that the credential header is present and valid in the form vLLM expects. This is classified as [CWE-444] Inconsistent Interpretation of HTTP Requests, also known as HTTP request smuggling-class confusion between server tiers. A related upstream advisory is documented in the X41-DSec Advisory X41-2026-002.

Attack Vector

Exploitation requires only network access to the vLLM HTTP endpoint and no prior authentication or user interaction. An attacker submits a crafted HTTP request to any protected OpenAI-compatible route — for example /v1/completions, /v1/chat/completions, or /v1/embeddings. The ASGI server forwards the request, starlette's middleware fails to reject it, and the handler processes the request as authenticated. The attacker receives model output, consumes GPU compute, and can probe loaded models without ever presenting the configured API key.

No verified public proof-of-concept code is available. Technical details are described in the GitHub Security Advisory GHSA-94f4 and the corresponding GitHub Pull Request Update.

Detection Methods for CVE-2026-48746

Indicators of Compromise

Successful HTTP 200 responses to /v1/completions, /v1/chat/completions, or /v1/embeddings from clients that never transmitted an Authorization: Bearer header matching VLLM_API_KEY.
Sudden increase in GPU utilization or inference request volume from unexpected source IP addresses.
Access log entries showing API requests with missing, malformed, or empty Authorization headers receiving non-401 responses.

Detection Strategies

Enable structured access logging on the ASGI server (uvicorn, hypercorn) and alert on requests reaching protected routes without a valid Authorization header.
Compare the set of source IPs hitting vLLM endpoints against the allowlist of approved API consumers.
Inspect HTTP request headers at the reverse proxy layer for malformed or smuggled authorization fields characteristic of the bypass.

Monitoring Recommendations

Forward vLLM and ASGI server logs to a centralized SIEM and build identifications for unauthenticated 2xx responses on /v1/* routes.
Track inference token usage per source identity and alert on anonymous or unattributed consumption.
Monitor for vLLM process versions across the fleet and flag any host still running a version earlier than 0.22.0.

How to Mitigate CVE-2026-48746

Immediate Actions Required

Upgrade vLLM to version 0.22.0 or later on every host running the OpenAI-compatible API server.
Place vLLM behind a reverse proxy or API gateway that enforces authentication independently of starlette middleware.
Restrict network exposure of vLLM endpoints to trusted client subnets until the upgrade is complete.
Rotate any VLLM_API_KEY values that may have been exposed during the vulnerable window.

Patch Information

The vLLM maintainers fixed the issue in release 0.22.0. The corrective changes are documented in the GitHub Pull Request Update and summarized in the GitHub Security Advisory GHSA-94f4. Operators should pin dependencies to vllm>=0.22.0 in deployment manifests and container images.

Workarounds

Terminate authentication at an upstream reverse proxy (nginx, Envoy, or a cloud API gateway) that validates bearer tokens before traffic reaches vLLM.
Bind vLLM to 127.0.0.1 or an internal interface and require mutual TLS for any external client.
Apply network-layer allowlists or service mesh policies that block unauthenticated callers from reaching the inference port.

bash

# Upgrade vLLM to the patched release
pip install --upgrade 'vllm>=0.22.0'

# Verify the installed version
python -c "import vllm; print(vllm.__version__)"

# Re-launch the API server with the API key enforced
vllm serve <model> --api-key "$VLLM_API_KEY" --host 127.0.0.1 --port 8000