Executive Summary

CVE-2026-34756 is a Denial of Service (DoS) vulnerability in the vLLM OpenAI-compatible API server caused by the lack of an upper bound on the 'n' parameter in the ChatCompletionRequest and CompletionRequest models.

An unauthenticated attacker can send a single HTTP request with an extremely large 'n' value, which causes the server to create millions of copies of the request object. This monopolizes the Python asyncio event loop and exhausts memory rapidly, leading to immediate Out-Of-Memory crashes and termination of the vLLM process.

The vulnerability arises because the 'n' parameter, which specifies how many output sequences to generate, has no enforced upper limit, allowing resource exhaustion attacks.

This issue was fixed in vLLM version 0.19.0 by adding upper bound validation on the 'n' parameter to prevent excessive resource allocation.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability allows any unauthenticated remote attacker to cause a complete denial of service on a public-facing vLLM API server with a single HTTP request.

The attack blocks the Python asyncio event loop by monopolizing CPU resources and causes rapid memory exhaustion by allocating millions of request copies, leading to immediate Out-Of-Memory crashes.

As a result, the vLLM service becomes unavailable, causing complete service disruption and impacting availability.

This can affect SaaS and AI-as-a-Service platforms using vLLM without strict payload validation or rate limiting, bypassing hardware capacity planning and bandwidth limitations.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability described in CVE-2026-34756 is a Denial of Service (DoS) issue that impacts the availability of the vLLM OpenAI-compatible API server by allowing unauthenticated attackers to exhaust system resources. It does not affect confidentiality or integrity of data.

Since the vulnerability does not involve unauthorized access to or disclosure of personal or sensitive data, it does not directly impact compliance with data protection regulations such as GDPR or HIPAA, which primarily focus on confidentiality and privacy of personal information.

However, the availability impact caused by this vulnerability could indirectly affect compliance if the affected service is critical for meeting regulatory requirements for uptime or service continuity.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring for unusually large values of the `n` parameter in HTTP requests sent to the vLLM OpenAI-compatible API endpoints, specifically `/v1/completions` and `/v1/chat/completions`.

Detection involves inspecting incoming API requests for the `n` parameter and identifying requests where `n` is set to an astronomically large number, which can cause resource exhaustion.

You can use network monitoring tools or HTTP request logging to capture and analyze these requests.

• Use command-line tools like `tcpdump` or `ngrep` to capture HTTP traffic to the vLLM server and filter for requests containing the `n` parameter.
• Example command to capture HTTP POST requests to the vLLM API (assuming default port 80): `tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -i 'n='`
• Alternatively, use `ngrep` to filter HTTP requests containing `n=`: `ngrep -W byline 'n=' tcp and port 80`

Additionally, monitor system metrics such as CPU usage, memory consumption, and process crashes (OOM kills) on the vLLM server, as the vulnerability causes high CPU blocking and rapid memory exhaustion.

Logs from the vLLM server or system logs indicating Out-Of-Memory (OOM) kills or crashes can also be indicators of exploitation attempts.

Useful 0 Not Useful 0

Mitigation Strategies

The primary immediate mitigation is to upgrade the vLLM software to version 0.19.0 or later, where the vulnerability is fixed by adding an upper bound validation on the `n` parameter.

If upgrading immediately is not possible, configure the environment variable `VLLM_MAX_N_SEQUENCES` to set a strict upper limit on the `n` parameter to prevent excessively large requests.

• Set `VLLM_MAX_N_SEQUENCES` to a conservative value such as 64 or 128 for public-facing deployments to reduce the risk of resource exhaustion.
• Reject or block requests where the `n` parameter exceeds this configured limit.

Implement additional protections such as reverse proxy layers to enforce request body validation and rate limiting to mitigate abusive payloads.

Monitor resource consumption per request to detect and respond to anomalous or abusive patterns early.

Useful 0 Not Useful 0