PYSEC-2026-4348: vLLM: Permissive default CORS origins allow cross-origin requests to the vLLM HTTP server
Summary
The OpenAI-compatible server registers Starlette CORSMiddleware with allowedorigins defaulting to [""], and performs no authentication unless --api-key (or VLLMAPIKEY) is configured. A web page on any origin can send requests to a vLLM server that the victim's browser can reach (for example localhost or an internal/VPN address) and read the responses. The default allowcredentials=False blocks cookie-bearing cross-origin requests; because vLLM authenticates with a bearer header rather than cookies, the wildcard still permits untokenized access to an unauthenticated server and read access when the caller already holds a token.
Details
Affected components
- vllm/entrypoints/launchers/cliargs.py - allowedorigins default value. - vllm/entrypoints/serve/middleware/register.py - CORSMiddleware registration. - vllm/entrypoints/serve/middleware/authenticate.py - auth middleware and its guarded path prefixes.
Root cause
vllm/entrypoints/launchers/cliargs.py:
python allowcredentials: bool = False """Allow credentials.""" allowedorigins: list[str] = field(defaultfactory=lambda: [""]) """Allowed origins."""
vllm/entrypoints/serve/middleware/register.py:
python app.addmiddleware( CORSMiddleware, alloworigins=args.allowedorigins, allowcredentials=args.allowcredentials, allowmethods=args.allowedmethods, allowheaders=args.allowedheaders, )
The auth middleware is added only when a token is configured and guards only the /v1, /v2, /inference, and /cohere prefixes. /v1/loadloraadapter and /v1/unloadloraadapter are inside /v1 and therefore do require a key when one is set; they are open only when no key is configured and dynamic LoRA updating is enabled.
Impact
- A malicious page can enumerate models (GET /v1/models), issue POST /v1/chat/completions, consume GPU time, and read model output through the victim's browser. - When the server is reachable only from the victim's network, the browser acts as a proxy a remote website could not otherwise use. - With allowcredentials=False, cookie-based CSRF does not apply; the exposure is cross-origin request execution and response disclosure.
This advisory was fixed in MR61009.
Other sources
vLLM is an inference and serving engine for large language models. Prior to 0.32.0, the OpenAI-compatible server configures Starlette CORSMiddleware with allowedorigins set to a wildcard by default. A malicious web page can use a victim's browser to reach an unauthenticated vLLM server on localhost, an internal network, or a VPN, call endpoints including GET /v1/models and POST /v1/chat/completions, consume GPU resources, and read responses. Cookie-based cross-site request forgery does not apply because credentials are disabled by default, and deployments requiring bearer authentication are exposed only when the caller already has a usable token. This issue is fixed in version 0.32.0.
— OSV
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/vllmto a version that resolves this vulnerability.Fixed in 0.32.0 - Upgrade
Upgrade
vllmto a version that resolves this vulnerability.Fixed in 0.32.0Patch MR61009
Event History
Frequently Asked Questions
Are deployments using the default server settings exposed?
Yes. The default allowed-origins setting is ["*"], and the server does not require authentication unless an API key is configured through --api-key or VLLM_API_KEY.
What must an attacker be able to do to exploit this?
An attacker needs to induce a victim to visit a web page they control. The victim's browser must be able to reach the vLLM HTTP server, such as through localhost, an internal network address, or a VPN-accessible address.
Does disabling cookie credentials prevent the issue?
No. The default allow_credentials=False prevents cookie-bearing cross-origin requests, but vLLM uses bearer-header authentication rather than cookies. It does not prevent untokenized access to an unauthenticated server or response reading by a caller that already has a token.
What can be changed if patching is not immediately possible?
Restrict allowed origins rather than using the wildcard default, and configure an API key using --api-key or VLLM_API_KEY. This removes unauthenticated access and limits which web origins can make browser-based requests.
How can an operator determine whether an instance is affected?
Check the effective allowed_origins configuration and whether an API key is configured. An instance using the default wildcard origin setting without an API key is exposed to requests from any origin reachable through a user's browser.