EUVD-2026-25892Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-accessible shared service with high complexity for timing recycled blocks; limited C/I/A impact mirrors CVSS 4.0 VC:L/VI:L/VA:L with no scope change.
Primary rating from Vendor (vuldb).
CVSS VectorVendor: vuldb
Lifecycle Timeline
6Blast Radius
ecosystem impact- 1 pypi packages depend on vllm (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.19.1.
DescriptionCVE.org
A vulnerability was found in vllm up to 0.19.0. The affected element is the function has_mamba_layers of the file vllm/v1/kv_cache_interface.py of the component KV Block Handler. Performing a manipulation results in uninitialized resource. It is possible to initiate the attack remotely. The attack is considered to have high complexity. The exploitability is described as difficult. The exploit has been made public and could be used. The patch is named 1ad67864c0c20f167929e64c875f5c28e1aad9fd. To fix this issue, it is recommended to deploy a patch.
AnalysisAI
Stale KV cache data leakage in vllm's KV Block Handler (versions 0.1-0.19.0) allows partial disclosure of prior inference requests' attention key/value data to subsequent requests. The needs_kv_cache_zeroing property incorrectly returned False for FullAttention model configurations - relying solely on has_mamba_layers - causing recycled KV cache blocks to go unzeroed between requests; partial-block tail slots retaining NaN/Inf values from prior sessions could then leak into the masked softmax computation of the next request. A publicly available PoC exists per SSVC and CVSS 4.0 E:P, though EPSS at 0.05% (14th percentile) and absence from CISA KEV indicate very low observed exploitation in practice.
Technical ContextAI
vllm is a high-throughput LLM inference engine that implements KV (Key-Value) cache block pooling to reuse intermediate attention computation memory across requests. In transformer FullAttention models, each block stores K/V tensors for a fixed number of token positions; when a request ends, its blocks are returned to the pool for reuse. The needs_kv_cache_zeroing property in vllm/v1/kv_cache_interface.py controls whether these recycled blocks are zeroed before reuse. The defect (CWE-908: Use of Uninitialized Resource) is that this property previously returned only self.has_mamba_layers, completely omitting FullAttention configurations (FullAttentionSpec). As a result, for all standard transformer attention models, recycled blocks were not zeroed - leaving 'partial-block tail slots' (memory positions not fully overwritten by the shorter of two consecutive requests) populated with stale K/V data, including potential NaN/Inf values that can propagate through masked softmax. CPE cpe:2.3:a:vllm:vllm:*:*:*:*:*:*:*:* covers all releases up to 0.19.0.
RemediationAI
The primary fix is to apply the upstream patch from commit 1ad67864c0c20f167929e64c875f5c28e1aad9fd (referenced in VulDB 359740) or monitor and merge PR #39283 at https://github.com/vllm-project/vllm/pull/39283, which extends needs_kv_cache_zeroing to return True for any FullAttentionSpec KV cache group. A specific tagged release version incorporating this fix is not independently confirmed in the available data - operators should monitor the vllm release stream beyond 0.19.0 and verify inclusion of this commit. As a compensating control for multi-tenant deployments where patch application is delayed, disabling KV cache block reuse between requests (enforcing per-request block isolation) eliminates the cross-request leak at the cost of significantly reduced inference throughput and increased GPU memory pressure. This trade-off may be acceptable for latency-tolerant or privacy-critical workloads but is not suitable for high-throughput production APIs.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Vllm versions up to 0.12.0 is affected by allocation of resources without limits or throttling (CVSS 6.5).
Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant gu
Remote code execution in vLLM 0.10.1 through 0.13.x lets an attacker who controls the model repository or path run arbit
Server-Side Request Forgery in vLLM's multimodal MediaConnector allows remote attackers to coerce the inference server i
Denial of service in vllm 0.19.0's OpenAI-compatible serving path allows remote unauthenticated attackers to exhaust sch
Same weakness CWE-908 – Use of Uninitialized Resource
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today