vLLM: OpenAI auth bypass

Vulnerability

In vLLM versions before v0.14.0, the AuthenticationMiddleware in vllm/entrypoints/openai/api_server.py (lines 689-692) extracts the url_path from a starlette URL object reconstructed from the request scope. The reconstruction uses the Host header value without validation, as f"{scheme}://{host_header}{path}" [1][3]. By including characters such as / or ? in the Host: header, an attacker can manipulate the reconstructed URL's .path attribute to avoid starting with /v1, thereby circumventing the token verification check (verify_token) that protects the OpenAI API endpoints. Affected environments are those that expose the API directly (not behind an RFC-conforming reverse proxy like nginx) and have configured an API key via VLLM_API_KEY or --api-key [1][3]. Starlette versions >= 0.8.3 (up to 1.0.1) are affected; vLLM depends on these versions [2].

Exploitation

An attacker needs network access to a vulnerable vLLM instance that is directly exposed (not behind nginx or similar) and has API key authentication enabled [1][3]. The exploit requires no authentication and no user interaction. The attacker sends an HTTP request where the Host: header contains path-delimiting characters, for example: a request line GET /v1/chat/completions HTTP/1.1 with Host: target.com/skip. The reconstructed URL becomes http://target.com/skip/v1/chat/completions, so url_path (after removeprefix(root_path)) no longer starts with /v1. The authentication check in AuthenticationMiddleware is then skipped, and the request is passed to the underlying application, which routes based on the actual HTTP path (from the request line) and processes the request as a valid API call [2][3].

Impact

Successful exploitation allows an attacker to call any OpenAI-compatible API endpoint without providing the required API key [1][3]. This results in unauthorized access to vLLM features such as model inference, potentially leading to information disclosure, resource abuse, or denial of service. The attacker gains the ability to use the API at the same privilege level as an authenticated user, with no restriction on the actions performed [3].

Mitigation

The vulnerability is fixed in vLLM by pull request #43426, which changes the path extraction to use the request's original path from the ASGI scope instead of the reconstructed URL [1][3]. Users should update vLLM to a version that includes this fix (committed but not yet released as a tag in the referenced PR). Deploying vLLM behind an RFC-conforming reverse proxy such as nginx (which normalizes or rejects malformed Host headers) fully mitigates the attack [1][3]. Until patched, ensure the vLLM API is not directly exposed to untrusted networks. Neither vLLM nor the upstream starlette (fixed in 1.0.1) are listed in CISA's Known Exploited Vulnerabilities catalog [2].