CVE-2026-71486 in vLLM
Summary
by MITRE • 08/17/2026
vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the /v1/completions/derender and /v1/chat/completions/derender endpoints accept caller-supplied GenerateResponse objects whose generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs, and routed_experts structures are processed by OnlineDerenderer and tokenizer.decode before max_model_len, max_tokens, max_num_seqs, or response-size limits are enforced, allowing an authenticated API client to consume excessive CPU and memory and produce oversized responses. This issue is fixed in version 0.26.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in vLLM versions prior to 0.26.0 represents a critical resource exhaustion flaw within the inference serving engine for large language models. Specifically, this issue affects the /v1/completions/derender and /v1/chat/completions/derender endpoints which are designed to process GenerateResponse objects provided by API clients. The core technical deficiency lies in the order of operations during request handling. When a client submits these requests, the system invokes OnlineDerenderer and tokenizer.decode on structures such as generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs, and routed_experts before validating or enforcing critical resource limits including max_model_len, max_tokens, max_num_seqs, or response-size constraints. This sequencing error allows an authenticated API client to supply maliciously crafted GenerateResponse objects that trigger excessive CPU consumption and memory allocation during the decoding process, ultimately resulting in oversized responses that can degrade service availability for other users.
From a security architecture perspective, this flaw is classified under CWE-787: Out-of-bounds Write if it leads to memory corruption, or more commonly in this context as CWE-400: Uncontrolled Resource Consumption due to the denial of service potential through resource exhaustion. The vulnerability aligns with MITRE ATT&CK technique T1496: Resource Hijacking, where an attacker leverages system resources for their own benefit or to disrupt services. Because authentication is required to exploit this flaw, it represents a threat from insider actors or compromised API keys rather than unauthenticated external attackers. However, the impact remains severe as it can lead to service degradation, increased operational costs due to excessive compute usage, and potential crashes of the inference engine if memory limits are exceeded without proper safeguards.
The exploitation mechanism relies on the fact that the tokenizer.decode function is computationally intensive and memory-heavy when processing large or malformed input structures. By sending requests with excessively long token sequences or complex logprob structures before length checks occur, an attacker can force the server to allocate significant amounts of RAM and CPU cycles. This bypasses the intended protective boundaries set by configuration parameters like max_model_len which are supposed to cap the context window size. The result is a denial-of-service condition where legitimate requests may be delayed or dropped due to resource contention, effectively rendering the large language model service unavailable until the affected instances are restarted or resources are reclaimed.
Mitigation strategies primarily involve upgrading vLLM to version 0.26.0 or later, which addresses this issue by enforcing size limits prior to processing these specific structures. For organizations unable to immediately upgrade, implementing strict input validation at a reverse proxy or API gateway layer can help filter out excessively large payloads before they reach the application logic. Additionally, configuring robust rate limiting and resource quotas per authenticated user can mitigate the impact of such attacks by capping the maximum allowable request size regardless of internal processing order. Monitoring for unusual spikes in CPU usage or memory consumption associated with these specific endpoints should also be prioritized to detect potential exploitation attempts early.