vLLM's wildcard CORS default let any website query local servers

The vLLM project has disclosed a flaw in its OpenAI-compatible HTTP server that allowed any website to send requests to a vLLM instance reachable by a victim's browser, and to read the responses. The advisory, GHSA-vvpg-rrww-wpmh, was published on 28 October 2026 and is tracked as CVE-2026-115917. It affects the vllm package on PyPI.

According to the advisory, the server registers Starlette's CORSMiddleware with allowed_origins defaulting to ["*"]. Cross-origin resource sharing, or CORS, is the browser rule that decides which other websites may read a server's responses. A wildcard setting means every website qualifies. The advisory adds that the server performs no authentication at all unless the operator configures --api-key or the VLLM_API_KEY environment variable.

The practical effect, the advisory says, is that a malicious page loaded in a victim's browser can enumerate available models through GET /v1/models, send POST /v1/chat/completions requests, consume GPU time and read the model's output. That matters most for servers that are not exposed to the public internet. Where a vLLM instance is reachable only on localhost, an internal network or a VPN address, the advisory says the victim's browser effectively acts as a proxy that a remote website could not otherwise use.

The advisory names three affected components: the allowed_origins default in vllm/entrypoints/launchers/cli_args.py, the middleware registration in vllm/entrypoints/serve/middleware/register.py, and the authentication middleware in vllm/entrypoints/serve/middleware/authenticate.py.

The advisory is careful about the limits of the issue. The default allow_credentials value is False, which blocks cookie-bearing cross-origin requests, so classic cookie-based cross-site request forgery does not apply. But vLLM authenticates using a bearer header rather than cookies. That means the wildcard still permits untokenized access to a server running without a key, and read access to responses when the calling page already holds a token. The exposure, in the advisory's words, is cross-origin request execution and response disclosure.

On the authentication side, the advisory says the auth middleware is only added when a token is configured, and that it guards only the /v1, /v2, /inference and /cohere path prefixes. It specifically addresses the adapter management endpoints /v1/load_lora_adapter and /v1/unload_lora_adapter, which load and unload LoRA fine-tuning weights at runtime. Because those paths sit inside /v1, they do require a key when one is set. They are open only when no key is configured and dynamic LoRA updating is enabled.

The advisory states that the issue was fixed in pull request 61009 in the vLLM repository. It does not describe any observed exploitation.

For teams running inference servers on developer laptops or internal hosts, the advisory is a reminder that a service bound to localhost is not private from the browser running on the same machine. Operators who have not set an API key and have not restricted allowed origins are, by the advisory's description, running an open endpoint that any visited web page can drive.