CVE-2026-73559: Uncontrolled Resource Consumption in vLLM API completions

The CVE-2026-73559 vulnerability represents an uncontrolled resource consumption flaw (CWE-400) within the OpenAI-compatible completions API of the vLLM serving framework.

In deployment scenarios, vLLM acts as a high-performance inference engine, optimizing GPU memory consumption and transaction throughput via advanced scheduling algorithms. The API exposes multiple endpoints, including /v1/completions, which ingest payloads modeled after the OpenAI API specification to support batch-processing capabilities.

Prior to version 0.26.0, the validation layers failed to enforce an upper limit on the number of elements supplied in input arrays. This architectural oversight allows an authenticated client to issue a single HTTP request containing an arbitrary number of nested prompt sequences, bypassing connection-level or thread-level rate limits.

Upon receiving such a request, the engine attempts to process every element concurrently, leading to downstream resource starvation. The system fans out tasks into individual async generators, depleting available memory buffers, and causing host-level or container-level crash states.

The root cause of the vulnerability resides in the lack of input length checks within the Pydantic schema deserialization path of CompletionRequest. Located in vllm/entrypoints/openai/completion/protocol.py, the schema specifies the prompt parameter as a highly flexible Union supporting multiple configurations, such as lists of token arrays.

When a list is provided, the data passes to vllm/renderers/inputs/preprocess.py where prompt_to_seq() is called. This function performs array expansion, parsing each index of the outer list as an independent input sequence to prepare for execution.

Next, the engine loops through these sequences inside the OnlineRenderer.preprocess_completion() method of vllm/renderers/online_renderer.py. For every sequence processed, vLLM schedules an independent model generation task.

The execution of these parallel tasks occurs inside vllm/entrypoints/openai/completion/serving.py by calling self.engine_client.generate(). Because there was no validation check on the outer array size, an input array containing tens of thousands of elements causes the engine to allocate an identical number of concurrent generator slots, exhausting the server's asynchronous event loops, request queues, and memory buffers.

The vendor addressed the vulnerability in version 0.26.0 by inserting a strict before-validation check on Pydantic models. This validation leverages a new configuration variable, VLLM_MAX_COMPLETION_PROMPTS, which restricts the maximum number of nested prompts allowed per request to a default of 1024.

Before the patch, the CompletionRequest class handled the prompt field without any array length verification, as shown in the original implementation:

# Original implementation lacking array length validation
prompt: Optional[Union[str, List[str], List[int], List[List[int]]]] = None

The patched version introduces an active Pydantic model validator inside vllm/entrypoints/openai/completion/protocol.py that intercepts the request dictionary before parsing:

# Patched implementation in protocol.py
@model_validator(mode="before")
@classmethod
def validate_prompt_list_length(cls, data):
    max_prompts = envs.VLLM_MAX_COMPLETION_PROMPTS
 
    prompt = data.get("prompt")
    if (
        isinstance(prompt, list)
        and len(prompt) > 0
        and not is_list_of(prompt, int)
        and len(prompt) > max_prompts
    ):
        raise VLLMValidationError(
            f"prompt list length {len(prompt)} exceeds the maximum "
            f"allowed count of {max_prompts}. To increase this "
            "limit, set the VLLM_MAX_COMPLETION_PROMPTS "
            "environment variable.",
            parameter="prompt",
        )
    return data

By implementing not is_list_of(prompt, int), the validator distinguishes between a single prompt composed of an array of token IDs (which must not be restricted by this logic) and a batch of multiple prompts. If the criteria are met and the list exceeds the maximum threshold, the validator immediately raises a VLLMValidationError, preventing downstream resource allocation.

Exploitation of CVE-2026-73559 requires network access to the target vLLM API server and authenticated client privileges where access control is enabled. The attack is straightforward, as it requires only standard JSON payload structures over HTTP POST.

To trigger the resource consumption condition, the attacker issues a request containing a single prompt parameter holding an array of 50,000 minimal string items. The HTTP payload structure matches the following standard model definition:

{
  "model": "meta-llama/Llama-3-8B-Instruct",
  "prompt": ["x", "x", "x", ... (repeated 50,000 times)],
  "max_tokens": 1
}

When the vLLM engine receives this payload, it bypasses connection-level limits because the server treats it as a single request. The diagram below represents the exact flow of the exploit vector leading to complete host starvation:

The execution of 50,000 individual generator loops rapidly exhausts the event queue and system memory, rendering the system unavailable to legitimate users and causing a hard process termination.

The impact of CVE-2026-73559 is rated as Medium (CVSS 6.5) due to its high availability impact, though it does not affect data confidentiality or integrity. Exploitation results in the immediate denial of service of the vLLM inference engine, affecting all workloads running on the same host.

To fully remediate this vulnerability, organizations must upgrade the vLLM package to version 0.26.0 or higher. This introduces the VLLM_MAX_COMPLETION_PROMPTS environment variable which limits the array depth at the schema layer.

In environments where immediate software upgrading is impossible, several defensive mitigations can be deployed:

1. Ingress API Gateway Validation: Configure a proxy layer like Envoy or NGINX to inspect the /v1/completions request body and reject requests containing prompt arrays with element counts exceeding 128.

2. Payload Size Restrictions: Set tight limits on HTTP POST body sizes (e.g., 512KB) to hinder the transmission of dense list payloads.

3. Network Isolation: Ensure the API server is restricted to trusted internal networks, minimizing exposure to untrusted entities.