GHSA-vvpg-rrww-wpmh: CSRF
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.
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 to a fixed release to a version that resolves this vulnerability.
Patch MR61009
Event History
Frequently Asked Questions
Which deployments are exposed to browser-based requests?
An OpenAI-compatible vLLM server is exposed when a victim's browser can reach it, such as on localhost or an internal or VPN-accessible address, and its CORS policy permits arbitrary origins. The default allowed-origins setting is ["*"].
What must an attacker do to exploit this?
The attacker needs to induce a victim to load a web page from any origin. That page can send requests to a reachable vLLM server and read its responses when the server permits unauthenticated access.
Does the default cookie restriction prevent this 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.
How can I determine whether my deployment has the risky configuration?
Check whether the OpenAI-compatible server is running without --api-key or VLLM_API_KEY and whether allowed_origins is left at its default value of ["*"]. Also determine whether users' browsers can reach the server from localhost, internal, or VPN-connected networks.