CVE-2026-116180 in vLLM
Summary
by MITRE • 10/25/2026
vLLM from 0.8.5 before 0.31.0 has a denial of service flaw. LogprobsTensors.empty_cpu() in vllm/v1/outputs.py allocates an uninitialized int32 tensor, and the V1 model runner leaves prompt positions reported as computed by a KV connector unwritten. A client sharing the engine can send prompt_logprobs (or echo with logprobs) against a connector-cached prefix, making tokenizer decode raise OverflowError, which crashes EngineCore and drops all co-tenant requests.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in vLLM versions prior to 0.31.0 represents a critical denial of service flaw rooted in improper memory initialization and state management within the model runner architecture. Specifically, the issue resides in the LogprobsTensors.empty_cpu() function located in the outputs module of version 0.8.5 through 0.31.0. This function allocates an uninitialized integer tensor with a data type of int32 without ensuring that the memory buffer is zeroed out or properly initialized before use. In many computing environments, particularly those involving CPU execution paths for large language model inference, accessing uninitialized memory can lead to undefined behavior. While this might not always result in immediate code execution vulnerabilities, it creates an unstable state where subsequent operations relying on predictable values may fail unpredictably. The core technical flaw is compounded by the logic within the V1 model runner, which incorrectly reports prompt positions as computed when they are actually left unwritten due to interactions with a KV connector caching mechanism. This discrepancy between reported and actual computational states forms the basis for the exploit vector.
The operational impact of this vulnerability manifests through a specific attack scenario involving multi-tenant environments where multiple clients share access to the same vLLM engine instance. An attacker can send a request containing prompt_logprobs or utilize an echo feature with logprobs enabled, targeting a prefix that has been cached by the KV connector. Because the underlying tensor was uninitialized and the position tracking logic is flawed, the tokenizer's decoding process encounters invalid data states. This triggers an OverflowError exception within the Python runtime environment of the engine core. Since vLLM operates as a long-running service handling inference requests, such unhandled exceptions cause the EngineCore to crash abruptly. The severity of this impact extends beyond the individual request that triggered the error; because the engine process terminates or becomes unstable, all co-tenant requests currently being processed or queued are dropped. This results in a complete denial of service for other legitimate users sharing the infrastructure, effectively allowing an attacker with minimal privileges to disrupt availability for the entire shared environment.
From a security classification perspective, this vulnerability aligns closely with CWE-120 Buffer Overflow and CWE-94 Improper Control of Generation of Code or Commands if interpreted broadly as improper handling leading to crash, but more accurately maps to CWE-787 Out-of-bounds Write in the context of uninitialized memory usage causing state corruption. In terms of adversary tactics, this aligns with MITRE ATT&CK technique T1499 Endpoint Denial of Service, specifically under subcategories involving resource exhaustion or service disruption through application crashes. The vulnerability highlights risks associated with shared infrastructure and improper isolation between tenant requests within a single process space. To mitigate this risk, organizations running vLLM must immediately upgrade to version 0.31.0 or later where the memory initialization logic has been corrected and the KV connector state management issues have been resolved. For environments that cannot update immediately, implementing strict request validation at the API gateway level to restrict access to logprob features for untrusted tenants can reduce exposure. Additionally, deploying health checks and automatic restart mechanisms with limited blast radius can help contain the impact of such crashes on multi-tenant deployments until a permanent patch is applied.