CVE-2026-94627
7.5vLLM Project · vLLM
The vLLM Mooncake connector fails to manage GPU KV cache block ownership, allowing attackers to trigger GPU memory exhaustion and prevent legitimate request execution.
Executive summary
A memory management flaw in the vLLM Mooncake connector allows unauthenticated attackers to cause a denial of service by exhausting GPU memory.
Vulnerability
This vulnerability involves improper management of GPU KV cache block ownership within the Mooncake connector, specifically when concurrent child requests share a single transfer ID. An unauthenticated attacker can submit completion requests with multiple prompts to force the accumulation of orphaned KV cache blocks, leading to persistent GPU memory exhaustion.
Business impact
The exploitation of this vulnerability results in a critical denial of service condition where the GPU memory becomes exhausted, preventing the vLLM instance from processing any legitimate inference requests. Given the CVSS score of 7.5, this high-severity flaw poses a significant operational risk to AI/ML infrastructure, potentially causing extended service outages that require a full process restart to clear the orphaned memory blocks.
Remediation
Immediate Action: Update the vLLM software to a version beyond 0.29.0 that includes the fix for KV cache block ownership management.
Proactive Monitoring: Monitor GPU memory utilization metrics and server logs for abnormal patterns of request failures or unexpected memory growth that persists between inference cycles.
Compensating Controls: Implement strict rate limiting on API endpoints that trigger completion requests to reduce the frequency and volume of requests that could be used to induce memory exhaustion.
Exploitation status
Public Exploit Available: No (exploit_available: unknown)
Analyst recommendation
Organizations utilizing vLLM with the Mooncake connector should prioritize patching to the latest version immediately to prevent potential service degradation. Since the vulnerability allows an attacker to effectively lock the system through memory exhaustion, applying the vendor-provided security update is the only definitive method to ensure stable and secure operation of the inference service.
More vLLM Project CVEs all →
History
- Disclosed CVE record published
- Collected by CVE Brief via github
- Analyst report written
- Published in the daily brief high section
Sources
Originally found and disclosed by Mingkai Yu, Jiapeng Li, Jiajia Liu, per the CVE Program record.
- Pull Request #49796 Issue tracker
- Technical analysis
- github.com
- VulnCheck Advisory: vLLM through 0.29.0 GPU KV Cache Leak via Mooncake Transfer ID Collision Third-party advisory