CVE-2026-94626 in vLLM
Summary
by MITRE • 09/22/2026
vLLM through 0.29.0 fails to validate the tp_size parameter in kv_transfer_params on OpenAI-compatible completion endpoints, allowing attackers to allocate unbounded memory. Attackers can supply arbitrary tp_size values in prefill/decode disaggregated deployments to exhaust memory and trigger kernel OOM-kill of the decode worker process.
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 versions through 0.29.0 represents a critical server-side request validation failure within its OpenAI-compatible completion endpoints. Specifically, the system fails to enforce bounds checking on the tp_size parameter when it is included in kv_transfer_params for prefill and decode disaggregated deployments. In these architectures, the workload is split between separate processes or nodes handling the initial token generation (prefill) and subsequent token decoding. The tp_size parameter dictates the tensor parallelism size, which directly influences memory allocation strategies for model weights and key-value cache structures. By omitting proper validation logic, the software allows clients to submit arbitrary integer values that are accepted without verification against system capabilities or configured limits.
This lack of input sanitization enables a remote attacker to exploit the resource management mechanisms by supplying excessively large tp_size values in their API requests. When such a request is processed, the vLLM engine attempts to allocate memory resources corresponding to the specified tensor parallelism size. Since there are no upper bounds or sanity checks applied before allocation, this action can lead to unbounded memory consumption on the host system. The immediate operational impact of this exploitation vector is severe resource exhaustion, specifically targeting the decode worker process which relies heavily on available RAM and VRAM for maintaining state during generation tasks.
The consequence of this memory exhaustion manifests as a kernel Out-Of-Memory (OOM) kill event. Linux kernels typically intervene when a process consumes more memory than is physically or virtually available by terminating the offending process to preserve system stability. In this context, the decode worker process is terminated abruptly, causing service disruption for all active inference sessions managed by that instance. This constitutes a Denial of Service condition where an unauthenticated attacker can effectively crash the serving infrastructure simply by sending malformed API requests with inflated tensor parallelism parameters. The attack does not require code execution or privilege escalation but relies entirely on misconfigured resource allocation logic within the application layer.
From a classification perspective, this vulnerability aligns closely with CWE-787: Out-of-bounds Write and CWE-400: Uncontrolled Resource Consumption. It also maps to MITRE ATT&CK technique T1496: Resource Hijacking, where an adversary uses computing resources for their own purposes or causes denial of service by exhausting system capacity. The specific mechanism involves manipulating configuration parameters that control internal resource distribution, leading to instability in distributed inference workloads.
Mitigation strategies must focus on implementing strict input validation and rate limiting at the API gateway level as well as within the vLLM application code itself. Developers should enforce maximum allowable values for tp_size based on hardware constraints or predefined deployment profiles before any memory allocation occurs. Additionally, integrating resource quotas per tenant or request can prevent a single malicious actor from monopolizing system resources. Upgrading to patched versions of vLLM that include these validation checks is the primary remediation path. Until patches are applied, administrators should restrict access to OpenAI-compatible endpoints and monitor for anomalous spikes in memory usage associated with completion requests containing unusual parameter sets.