CVE-2026-34756: 
NixOS vulnerability analysis and mitigation

CVE-2026-34756 is an unauthenticated Out-of-Memory (OOM) Denial of Service vulnerability in the vLLM OpenAI-compatible API server, caused by the absence of an upper bound on the n parameter in ChatCompletionRequest and CompletionRequest Pydantic models. It affects vLLM versions 0.1.0 through 0.18.x (all versions before 0.19.0). The vulnerability was published on April 3, 2026, via GitHub Advisory GHSA-3mwp-wvh9-7528, and registered in the NVD on April 6, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, Red Hat Bugzilla).

The root cause spans three layers of the vLLM stack, classified as CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-1284 (Improper Validation of Specified Quantity in Input). At the protocol layer, vllm/entrypoints/openai/chat_completion/protocol.py defines n: int | None = 1 with no pydantic.Field upper bound constraint. At the SamplingParams layer (vllm/sampling_params.py), the _verify_args method only checks self.n < 1, omitting any upper bound check. When the request reaches the engine (vllm/v1/engine/async_llm.py), it fans out the request n times in a synchronous for loop using copy(request), which monopolizes Python's single-threaded asyncio event loop and drives heap memory usage up by gigabytes per second until the OS OOM-killer terminates the process (Github Advisory, Fix PR).

Successful exploitation results in complete availability loss of the vLLM inference server — a single malicious HTTP request can crash the process via OOM termination and simultaneously block all other connections by monopolizing the asyncio event loop, including liveness probes. There is no confidentiality or integrity impact. Organizations most at risk include those hosting public-facing vLLM API servers and SaaS/AI-as-a-Service platforms using vLLM as a backend without strict HTTP body validation or rate limiting at the reverse proxy layer (Github Advisory).

No public exploit code or in-the-wild exploitation has been reported as of the time of writing. The EPSS score is approximately 0.028–0.049%, placing it in the 16th percentile for exploitation likelihood within 30 days (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. While no authentication is required to reach the API endpoint in many default deployments, the CVSS score reflects that low-privilege access (e.g., a valid API key) may be required in some configurations. The attack requires only a single crafted HTTP request with no special tooling, making it trivially reproducible by any attacker with network access to the API server.

1. Reconnaissance: Identify internet-facing vLLM API servers (versions 0.1.0–0.18.x) using tools like Shodan or Censys, searching for services exposing /v1/chat/completions or /v1/completions endpoints.
2. Obtain API access: If the target requires authentication, obtain a valid API key (e.g., through credential theft, trial accounts, or misconfigured open deployments).
3. Craft malicious request: Construct an HTTP POST request to /v1/chat/completions or /v1/completions with an astronomically large n value (e.g., 100,000,000) in the JSON body:

{
  "model": "<target-model>",
  "messages": [{"role": "user", "content": "test"}],
  "n": 100000000,
  "max_tokens": 1
}

4. Send the request: Transmit the single HTTP request to the target server using curl, httpx, or any HTTP client.
5. Trigger OOM crash: The engine's fan-out loop begins allocating millions of copy(request) objects in the heap, exhausting memory within seconds and blocking the asyncio event loop, causing the OS OOM-killer to terminate the vLLM process and taking down the inference service (Github Advisory, Fix PR).

• Network: Single HTTP POST requests to /v1/chat/completions or /v1/completions with unusually large JSON body payloads; requests containing an n field with an integer value in the millions or higher.
• Logs: Web server or reverse proxy access logs showing a POST to the completions endpoint immediately followed by connection drops or 502/503 errors from the vLLM backend; vLLM process logs showing sudden termination without graceful shutdown.
• Process/System: Rapid spike in the vLLM process's Resident Set Size (RSS) memory consumption to gigabytes within seconds; OOM-killer log entries in /var/log/kern.log or dmesg referencing the vLLM Python process (e.g., Out of memory: Killed process <pid> (python)).
• Availability: Sudden unresponsiveness of the vLLM API server to all requests, including health/liveness probes, immediately following a single inbound request.

Upgrade vLLM to version 0.19.0 or later, which introduces the VLLM_MAX_N_SEQUENCES environment variable (default: 16384) and enforces an upper bound check in SamplingParams._verify_args, rejecting requests that exceed the limit before they reach the engine (Fix PR, Fix Commit). For public-facing deployments, set VLLM_MAX_N_SEQUENCES to a conservative value appropriate for your workload (e.g., 64 or 128). As an additional layer of defense, deploy vLLM behind a reverse proxy (e.g., nginx) configured to enforce request body size limits, rate limiting, and payload validation to reject requests with abnormally large n values before they reach the vLLM process (Github Advisory).

The vulnerability was coordinated and disclosed by vLLM maintainer russellb (Russell Bryant) with jperezdealgaba as the remediation developer, and reporter credited as ez-lbz. Red Hat tracked the issue via Bugzilla (Bug 2455425) with high severity, indicating relevance to enterprise AI deployments (Red Hat Bugzilla). The fix was merged on March 27, 2026, prior to the public advisory on April 3, 2026, reflecting a responsible disclosure process. No significant broader media coverage or notable social media reactions have been identified beyond standard vulnerability database aggregation.