CVE-2026-73559 in vLLMinfo

Summary

by MITRE • 08/13/2026

vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.26.0, the /v1/completions CompletionRequest.prompt field in vllm/entrypoints/openai/completion/protocol.py accepts an unbounded list[str] or list[list[int]], prompt_to_seq() in vllm/renderers/inputs/preprocess.py and OnlineRenderer.preprocess_completion() in vllm/renderers/online_renderer.py expand every element, and vllm/entrypoints/openai/completion/serving.py creates one engine generator and response slot per prompt, allowing an authenticated API client to exhaust CPU, memory, async scheduling capacity, engine request slots, and response buffering with one request. This issue is fixed in version 0.26.0.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 08/13/2026

The vulnerability identified in vLLM versions 0.19.0 through 0.26.0 represents a critical resource exhaustion flaw that enables authenticated API clients to perform denial of service attacks against the inference engine. This vulnerability stems from insufficient input validation and processing logic within the completion endpoint handling code, specifically affecting the /v1/completions API route that processes prompt data for language model inference operations.

The technical flaw manifests in how the CompletionRequest.prompt field processes input data structures. The system accepts unbounded list[str] or list[list[int]] types without proper size limitations or validation checks, allowing attackers to submit extremely large prompt sequences that can cause significant system resource consumption. When these inputs are processed through the prompt_to_seq() function in vllm/renderers/inputs/preprocess.py and subsequently handled by OnlineRenderer.preprocess_completion() in vllm/renderers/online_renderer.py, each element within the input lists gets expanded individually, creating exponential resource allocation demands.

The operational impact of this vulnerability extends beyond simple resource exhaustion to encompass complete system degradation. Each malicious request triggers the creation of one engine generator and response slot per prompt element, leading to massive consumption of CPU cycles, memory allocation, async scheduling overhead, and engine request slots. This process effectively allows a single authenticated client to overwhelm the entire serving infrastructure by submitting carefully crafted inputs that expand into thousands or millions of individual processing tasks.

This vulnerability aligns with CWE-400 (Uncontrolled Resource Consumption) and represents a classic example of a resource exhaustion attack pattern that can be categorized under ATT&CK technique T1499.1 (Network Denial of Service) and T1583.001 (Preparation: Account Access). The flaw demonstrates poor input sanitization practices where the system fails to implement proper bounds checking or rate limiting mechanisms for prompt processing, creating an avenue for attackers to consume disproportionate system resources relative to the initial request size.

The fix implemented in version 0.26.0 addresses this issue by introducing proper input validation and resource limits within the prompt processing pipeline. Organizations should immediately upgrade to version 0.26.0 or later to mitigate this vulnerability, while implementing additional monitoring for unusual API usage patterns that might indicate exploitation attempts. Network-level rate limiting and request size restrictions should also be considered as defensive measures to protect systems running affected versions of vLLM from potential abuse.

This vulnerability highlights the importance of input validation in AI inference systems where processing large inputs can exponentially increase computational requirements, making proper bounds checking essential for maintaining system stability and availability. The issue serves as a reminder that even well-established machine learning frameworks require careful attention to resource management when handling user-provided data that can be manipulated to cause system-wide performance degradation or complete service unavailability.

Responsible

GitHub M

Reservation

08/12/2026

Disclosure

08/13/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you need the next level of professionalism?

Upgrade your account now!