CVE-2026-115917

What it actually does

The OpenAI-compatible server in vLLM enables Starlette CORSMiddleware with a wildcard allowed_origins by default, permitting any origin to issue cross-origin requests to endpoints such as /v1/models and /v1/chat/completions on unauthenticated instances reachable from localhost, internal networks, or VPNs.

Why it matters to the business

Organizations running vLLM inference servers face unauthorized GPU resource consumption and potential leakage of model outputs when users visit malicious websites, increasing operational costs and risking exposure of proprietary AI interactions without requiring stolen credentials.

How an attack unfolds

An attacker hosts a malicious webpage that executes JavaScript fetch or XMLHttpRequest calls against the victim's browser-reachable vLLM instance; the wildcard CORS policy allows the browser to forward requests and return responses containing model data or confirmation of compute usage.

How to fix it

Upgrade all vLLM deployments to version 0.32.0 or later and explicitly configure allowed_origins to a strict allowlist instead of the default wildcard; disable or restrict the OpenAI-compatible server when not required.

How to confirm the fix worked

Confirm running version is 0.32.0+, inspect Starlette CORSMiddleware configuration for non-wildcard origins, and test from a different origin that requests are now blocked or require explicit preflight approval.

Typical attack path

1. Victim visits attacker-controlled webpage while an unauthenticated vLLM server is reachable via browser (localhost, LAN, or VPN)
2. Page issues cross-origin GET /v1/models or POST /v1/chat/completions requests
3. CORS preflight and actual requests succeed due to wildcard origin policy
4. Responses containing model metadata or generated text are read by the page and exfiltrated to attacker
5. Repeated calls consume GPU resources on the target server

How to detect it

Review web server or application logs for cross-origin requests to /v1/models and /v1/chat/completions originating from unexpected referrers or lacking authentication headers; correlate with browser history or proxy logs showing visits to unknown domains shortly before such calls.

What your security team should do

• Immediately upgrade to vLLM 0.32.0 across all instances
• Audit network exposure of vLLM servers and restrict to authenticated, non-browser-accessible endpoints
• Implement strict CORS allowlists and consider adding authentication tokens even for internal deployments
• Monitor for unexpected traffic to /v1/* endpoints from external referrers