Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-21T22:17:01.740Z",
  "pubdate": "2026-09-21T22:17:01.740Z",
  "executiveSummary": "A memory management vulnerability exists in the vLLM Mooncake connector through version 0.29.0, characterized by improper GPU KV cache block ownership handling.\nThe flaw occurs in disaggregated prefill/decode deployments when concurrent child requests utilize a shared transfer ID, leading to a permanent leakage of GPU memory blocks.\nThis vulnerability constitutes a Denial of Service (DoS) risk, as an attacker can repeatedly trigger orphaned cache allocations that remain resident in GPU memory until the process is restarted.\nBy submitting completion requests containing multiple prompts, unauthorized users can cause rapid memory exhaustion, effectively preventing the system from processing legitimate inference requests.\nExploitation does not require elevated privileges, as the impact is realized through the standard request submission interface.\nThe inability of the system to reclaim leaked memory blocks necessitates an application restart to restore operational capacity, posing significant availability risks for production serving environments.",
  "technicalDetails": "The vulnerability resides within the Mooncake connector's logic for managing KV cache block lifecycle during disaggregated inference. In configurations where prefill and decode tasks are decoupled, the connector relies on a transfer ID mechanism to track and share cache block ownership between concurrent operations.\nThe root cause is a race condition or logic failure in the ownership tracking mechanism when multiple child requests are associated with a single transfer ID. When the vLLM instance processes these concurrent requests, the internal state machine fails to correctly decrement the reference count or release the allocated GPU memory blocks upon request completion.\nThe attack flow proceeds as follows: 1) An attacker submits a crafted completion request containing multiple concurrent prompts designed to trigger the shared transfer ID logic. 2) The Mooncake connector initializes the KV cache allocation for these prompts. 3) Due to the faulty ownership management, the system creates orphaned blocks that are disconnected from the primary cache tracking table but remain allocated in the GPU's VRAM. 4) Subsequent requests from the attacker exacerbate this accumulation, as the orphaned blocks are never freed by the garbage collection or reference counting mechanisms.\nBecause the vLLM process does not implement an automatic memory reclamation or health-check sweep for these orphaned blocks, the GPU VRAM capacity is permanently diminished with each successful exploitation cycle.\nThis behavior results in a progressive 'memory leak' that continues until the GPU reaches a state of exhaustion, where further allocations (including those for benign requests) fail, resulting in an OOM (Out of Memory) condition and service denial.\nThe vulnerability affects all vLLM Mooncake connector versions through 0.29.0. There are no authentication requirements for this attack, as the exploitation is achieved through the primary API interface provided by the model serving deployment. The attack is restricted to the memory space of the affected vLLM worker nodes and does not involve lateral movement, but the post-exploitation impact is a total loss of service availability for the target inference instance."
}