CVE-2026-94623 in vLLM
Summary
by MITRE • 09/22/2026
vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation that fails to properly validate block counts across multi-prompt completion requests in prefill/decode disaggregated deployments. Attackers can trigger an assertion failure in NixlBaseConnectorWorker._apply_prefix_caching by submitting completion requests with multiple prompts of varying lengths, causing the decode worker to terminate and become unavailable until restarted.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified within vLLM versions up to 0.29.0 represents a critical denial of service flaw located in the NIXL connector's prefix caching implementation. This issue specifically affects deployments that utilize prefill/decode disaggregation, an architecture where the computational workload is split between different workers or nodes to optimize inference performance. In such setups, the system relies on precise synchronization and state consistency between the prefill worker, which handles initial token generation, and the decode worker, which manages subsequent token output. The NIXL connector serves as a critical communication layer facilitating data transfer and cache management in these distributed environments. When handling multi-prompt completion requests where prompts vary significantly in length, the system fails to properly validate block counts across these disparate inputs. This lack of rigorous validation leads to an internal state inconsistency that triggers an assertion failure within the NixlBaseConnectorWorker._apply_prefix_caching function. The consequence is immediate and severe: the decode worker process terminates abruptly due to the unhandled exception caused by the failed assertion, rendering it unavailable until manual intervention or automatic restart mechanisms are triggered.
From a technical perspective, this vulnerability stems from insufficient input validation regarding block allocation metrics during prefix caching operations. Prefix caching is designed to reuse previously computed intermediate results for similar prompt prefixes, thereby reducing latency and computational overhead. However, when multiple prompts of varying lengths are processed concurrently in a disaggregated architecture, the logic governing how these blocks are mapped and validated becomes susceptible to edge cases that were not adequately accounted for during development. The assertion failure indicates that the code expected certain conditions regarding block counts or memory alignment that are violated by specific combinations of prompt lengths. Because this occurs within the core worker loop responsible for applying prefix caching, the error is fatal to the process rather than being recoverable at a higher application level. This highlights a gap in defensive programming practices where internal assumptions about data integrity were not enforced with robust validation checks suitable for production-grade distributed systems handling variable-length inputs.
The operational impact of this vulnerability is primarily characterized by service disruption and reduced availability. Since the decode worker terminates upon encountering the malformed request sequence, any ongoing inference tasks are interrupted, leading to immediate loss of connectivity for clients relying on that specific node or process. In a high-throughput production environment, such interruptions can cause cascading failures if load balancers do not adequately handle sudden node unavailability or if retry logic is insufficiently resilient. The requirement for manual restarts further exacerbates the impact by introducing downtime periods during which the service remains degraded until operations personnel intervene. This directly affects the reliability and uptime guarantees of applications built on vLLM, particularly those serving real-time inference workloads where consistency and availability are paramount. Attackers can exploit this by crafting specific multi-prompt completion requests with carefully chosen varying lengths to reliably trigger the assertion failure, effectively creating a persistent denial of service condition against the targeted deployment.
This vulnerability aligns with CWE-20 Improper Input Validation, as the root cause is the failure to adequately sanitize or verify input parameters before processing them within critical system functions. Additionally, it relates to CWE-617 Reachable Assertion, which describes situations where an assertion can be triggered by external inputs due to insufficient precondition checks. From a threat modeling perspective using the MITRE ATT&CK framework, this behavior is consistent with T1499 Endpoint Denial of Service, specifically under techniques that involve exhausting system resources or crashing processes through malformed requests. The attack vector requires network access to submit completion requests, classifying it as an exploitable remote vulnerability in contexts where vLLM exposes its API endpoints publicly or within untrusted internal networks.
Mitigation strategies should focus on immediate patching and architectural hardening. Organizations running affected versions of vLLM must upgrade to a version later than 0.29.0, which presumably contains the necessary fixes for block count validation in the NIXL connector's prefix caching logic. Until an update is applied, administrators can implement network-level controls such as rate limiting or request size restrictions to reduce the likelihood of triggering the specific conditions that lead to the assertion failure. Additionally, deploying health checks and automated restart policies within container orchestration platforms like Kubernetes can help minimize downtime by automatically restarting terminated decode workers, although this does not prevent the initial service disruption caused by each successful attack attempt. Long-term remediation should also involve reviewing other areas of the NIXL connector for similar validation gaps to ensure robustness against future edge-case exploits in distributed inference architectures.