CVE-2026-94624 in vLLM
Summary
by MITRE • 09/22/2026
vLLM through 0.29.0 contains a denial of service vulnerability in P2P KV offloading when OffloadingConnector is configured with TieringOffloadingSpec and a peer-to-peer secondary tier. Attackers can supply arbitrary remote host and port values in kv_transfer_params to create unreachable peer sessions that retain ZeroMQ sockets until the context quota is exhausted, causing an uncaught ZMQError that crashes EngineCore and stops all inference.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in vLLM versions up to 0.29.0 represents a critical denial of service flaw within its peer-to-peer key-value cache offloading mechanism. This specific component, known as the OffloadingConnector, is designed to manage data transfer between different tiers of storage or compute resources using a TieringOffloadingSpec configuration that includes a peer-to-peer secondary tier. The core issue arises from insufficient input validation when handling remote connection parameters provided by users through the kv_transfer_params interface. Specifically, the system fails to verify whether the supplied host and port values correspond to reachable network endpoints before attempting to establish communication sessions via ZeroMQ sockets. This lack of validation allows an attacker to inject arbitrary or non-existent network addresses into the configuration payload.
When such malicious parameters are processed, the vLLM engine attempts to initialize peer-to-peer connections using these unreachable targets. Each failed connection attempt results in the creation and retention of a ZeroMQ socket object that remains open but inactive because it cannot establish a valid handshake with the specified remote host. Over time, as more invalid requests are submitted, these orphaned sockets accumulate within the process memory space. The system relies on a context quota to limit resource consumption, but the current implementation does not adequately handle or clean up these failed socket instances before they consume available resources. Consequently, the accumulation of unreachable peer sessions eventually exhausts the ZeroMQ context quota, leading to an uncaught ZMQError exception that crashes the EngineCore process.
The operational impact of this vulnerability is severe for any production environment relying on vLLM for large language model inference services. Since the crash affects the EngineCore component, which is central to the execution pipeline, a single successful exploitation attempt can bring down the entire inference service. This results in immediate availability loss for all users and applications depending on that instance. Unlike vulnerabilities that might allow remote code execution or data exfiltration, this flaw is strictly focused on disrupting service continuity by exhausting system resources through malformed network configuration inputs. The attacker does not need elevated privileges to trigger this condition; any user with access to the API endpoint responsible for configuring KV transfer parameters can initiate the resource exhaustion attack.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write or Access if interpreted broadly as improper handling of resources leading to system instability, though it is more accurately categorized under CWE-400 Uncontrolled Resource Consumption which leads to Denial of Service. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1499 Endpoint Denial of Service, specifically through resource exhaustion techniques that target application-level services rather than operating system resources directly. The attack vector is remote if the vLLM service exposes its API over a network, making it accessible to external adversaries who can craft and submit malicious kv_transfer_params payloads.
Mitigation strategies should focus on both immediate patching and architectural hardening. The primary remediation is to upgrade vLLM to version 0.29.1 or later where this validation logic has been corrected. For environments that cannot immediately update, implementing strict input validation at the API gateway level can prevent malicious parameters from reaching the application layer. This includes validating hostnames against a whitelist of allowed domains and ensuring port numbers fall within expected ranges for internal communication. Additionally, configuring ZeroMQ contexts with stricter limits or implementing automatic cleanup routines for failed socket connections can mitigate the risk of resource exhaustion even if invalid inputs are processed. Monitoring system logs for repeated connection failures to unreachable hosts can also provide early detection signals for potential exploitation attempts before the context quota is fully exhausted.