CVE-2026-94627 in vLLM
Summary
by MITRE • 09/22/2026
vLLM Mooncake connector through 0.29.0 fails to properly manage GPU KV cache block ownership when concurrent child requests share a single transfer ID in prefill/decode disaggregated deployments. Attackers can trigger GPU memory exhaustion by submitting completion requests with multiple prompts, causing orphaned KV cache blocks to accumulate until process restart and eventually preventing legitimate requests from executing.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in vLLM Mooncake connector versions up to 0.29.0 represents a critical resource management flaw within the context of prefill-decode disaggregated inference deployments. In these architectures, the system separates the computational heavy lifting of generating initial tokens (prefill) from the iterative generation of subsequent tokens (decode). This separation relies on efficient memory sharing mechanisms, specifically utilizing GPU Key-Value cache blocks to store intermediate attention states for ongoing requests. The Mooncake connector facilitates this data transfer between distinct service instances or processes. However, a fundamental logic error exists in how ownership and lifecycle management of these KV cache blocks are handled when concurrent child requests share a single transfer identifier during the prefill phase.
The technical root cause lies in the failure to properly track and release GPU memory allocations associated with specific request contexts. When multiple prompts are submitted as part of a completion request that shares a unified transfer ID, the system incorrectly assumes shared ownership or fails to establish distinct boundaries for each prompt's cache blocks. As these requests progress through the inference pipeline, the KV cache blocks allocated for individual prompts within this batched group do not get correctly deallocated upon request completion or termination. Instead of being returned to the available memory pool, these blocks become orphaned, remaining locked in GPU memory despite no longer serving any active computational purpose. This accumulation occurs because the cleanup routines are either bypassed or misaligned with the actual state of the concurrent child requests sharing that specific transfer ID.
The operational impact of this vulnerability is severe and directly affects system availability through resource exhaustion. As attackers submit completion requests containing multiple prompts, they trigger a continuous leak of GPU memory resources. Since GPUs have finite VRAM capacity, the accumulation of these orphaned KV cache blocks rapidly depletes available memory. This leads to a state where legitimate inference requests cannot be allocated sufficient memory to execute, effectively causing a denial of service for all users relying on the model serving infrastructure. The only current mitigation within the affected software version is restarting the vLLM process or the Mooncake connector instance, which clears the leaked memory but does not resolve the underlying logic flaw and results in temporary downtime and loss of ongoing inference sessions.
From a classification perspective, this vulnerability aligns with CWE-401, Missing Release of Memory after Effective Lifetime, as well as CWE-787, Out-of-bounds Write, if the improper management leads to memory corruption beyond just leakage. In terms of attack vectors, it falls under ATT&CK technique T1496, Resource Hijacking, specifically involving computational resource exhaustion via denial of service. The exploitation does not require authentication in many default configurations and can be triggered remotely by sending malformed or strategically crafted inference requests that exploit the shared transfer ID logic.
To mitigate this vulnerability, immediate action is required to upgrade vLLM Mooncake connector to a version later than 0.29.0 where the memory management logic for KV cache blocks has been corrected. Until an update can be applied, operators should implement strict rate limiting on completion requests that involve multiple prompts or shared transfer IDs to reduce the frequency of exploitation attempts. Additionally, monitoring GPU memory usage metrics and setting up automated alerts for abnormal spikes in VRAM consumption can help detect active exploitation early. Implementing circuit breakers that automatically restart affected services when memory thresholds are exceeded may also serve as a temporary operational safeguard to maintain partial availability while permanent patches are deployed.