CVE-2026-115917: 
NixOS vulnerability analysis and mitigation

CVE-2026-115917 is a CORS misconfiguration vulnerability in vLLM's OpenAI-compatible HTTP server that allows malicious web pages to make cross-origin requests to vLLM instances reachable by a victim's browser. Affecting all versions of vLLM prior to 0.32.0, the server configured Starlette's CORSMiddleware with allowed_origins defaulting to a wildcard (["*"]), enabling any web origin to call endpoints such as GET /v1/models and POST /v1/chat/completions. The vulnerability was disclosed on October 26, 2026, and fixed in vLLM v0.32.0. It carries a CVSS v3.1 base score of 4.7 (Medium) per NVD, and 3.4 (Low) per the GitHub Security Advisory (GitHub Advisory, Feedly).

The root cause lies in two source files: vllm/entrypoints/launchers/cli_args.py, where allowed_origins defaults to ["*"], and vllm/entrypoints/serve/middleware/register.py, where this value is passed directly to Starlette's CORSMiddleware without restriction (CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains; CWE-346: Origin Validation Error). Because allow_credentials defaults to False, cookie-based CSRF is not applicable; however, the wildcard CORS policy still permits any browser origin to read API responses from unauthenticated vLLM servers or from servers where the attacker already possesses a bearer token. The attack requires user interaction — a victim must visit a malicious web page — and the vLLM server must be reachable from the victim's browser (e.g., localhost, internal network, or VPN). The fix, merged via PR #61009, changes the default allowed_origins to an empty list in both the Python (cli_args.py) and Rust (cli.rs, config.rs) serving frontends, requiring operators to explicitly opt in to browser origins (GitHub Advisory, Fix Commit).

A malicious web page can leverage a victim's browser as a proxy to enumerate available models (GET /v1/models), submit inference requests (POST /v1/chat/completions), consume GPU compute resources, and read model responses — all without direct network access to the vLLM server. The primary impact is unauthorized information disclosure (model names, inference outputs) and resource abuse (GPU exhaustion), with no integrity or availability impact beyond resource consumption. Deployments requiring bearer authentication are only exposed when the attacker already possesses a valid token; unauthenticated deployments on localhost or internal networks are the primary risk (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). No threat actor attribution is available. The EPSS score is approximately 0.0024 (0.24%), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires user interaction (victim visiting a malicious page) and the vLLM server being reachable from the victim's browser, limiting the practical attack surface primarily to internal/developer deployments.

1. Identify a target: Determine that a victim has access to a vLLM server (e.g., running on localhost:8000, an internal network address, or a VPN-accessible host) running a version prior to 0.32.0 without API key authentication.
2. Craft a malicious web page: Create an HTML page with JavaScript that issues cross-origin fetch requests to the vLLM server, such as:

fetch('http://localhost:8000/v1/models')
  .then(r => r.json())
  .then(data => exfiltrate(data));

3. Deliver the page to the victim: Host the malicious page on an attacker-controlled domain and trick the victim into visiting it (e.g., via phishing, malicious ad, or compromised site).
4. Browser executes cross-origin request: Because vLLM's default CORS policy returns Access-Control-Allow-Origin: *, the victim's browser allows the JavaScript to read the response, bypassing the same-origin policy.
5. Exfiltrate results or abuse resources: The attacker's script reads model names, submits inference prompts via POST /v1/chat/completions, and sends responses to an attacker-controlled server — consuming GPU resources and potentially leaking sensitive model outputs (GitHub Advisory, Fix PR).

• Network: Unexpected cross-origin HTTP requests to vLLM API endpoints (e.g., GET /v1/models, POST /v1/chat/completions) originating from browser user-agents with Origin headers pointing to external or untrusted domains; unusual spikes in inference request volume from localhost or internal clients.
• Logs: vLLM access logs showing requests with Origin: headers from unknown external domains (e.g., Origin: http://attacker.example) receiving 200 OK responses with Access-Control-Allow-Origin: *; abnormal GPU utilization correlated with unexpected API calls.
• Process/Resource: Unexplained GPU memory or compute spikes on vLLM host systems without corresponding legitimate user activity; high inference throughput during off-hours.

Upgrade vLLM to version 0.32.0 or later, which changes the default allowed_origins from ["*"] to [] (no cross-origin access) in both Python and Rust serving frontends (vLLM v0.32.0 Release). For deployments that cannot upgrade immediately, explicitly restrict CORS origins by launching vLLM with --allowed-origins '["https://trusted.example.com"]' instead of relying on the default. Additionally, implement network-level access controls (firewall rules, VPN segmentation) to limit which hosts can reach the vLLM server, and enable API key authentication via --api-key or the VLLM_API_KEY environment variable to require bearer tokens for all requests (GitHub Advisory).

The vulnerability was reported by researcher prnjlksingh and coordinated by jperezdealgaba from the vLLM project team, who also authored the fix (GitHub Advisory). The fix was reviewed and merged by vLLM maintainer DarkLight1337 on October 11, 2026, with Claude AI-assisted code review confirming no high-confidence issues in the change (Fix PR). Red Hat tracked the issue via Bugzilla (Bug #2560981) and published a CVE advisory, reflecting the vulnerability's relevance to enterprise AI infrastructure deployments (Red Hat CVE).