vLLM CVE-2026-94626

Requires the vLLM instance to be running in a prefill/decode (P/D) disaggregated deployment, where kv_transfer_params is honored on the OpenAI-compatible completion endpoints (/v1/completions, /v1/chat/completions). The attacker must be able to send requests to that endpoint (no authentication or user interaction is required per PR:N/UI:N), and supplies an arbitrary large tp_size (the fix rejects values ≤0, non-integers, and values above _MAX_KV_TRANSFER_TP_SIZE). What limits exploitation: standard single-node/non-disaggregated vLLM deployments that do not process kv_transfer_params are not affected, and endpoints that are network-restricted or gated behind an authenticating proxy reduce exposure; impact is limited to availability (decode-worker OOM-kill / service disruption), with no data disclosure or code execution.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H, score 8.7) describes a purely availability-impacting flaw reachable over the network without authentication or user interaction - confidentiality and integrity impacts are explicitly N. This is consistent with CWE-789 (memory allocation with excessive size value) and the description: an unvalidated tp_size drives unbounded allocation that OOM-kills the decode worker. The 'RCE' input tag is contradicted by every other signal - there is no code-execution, integrity, or confidentiality impact anywhere in the vector or description; this is a denial-of-service issue and the tag should be treated as mislabeled. No EPSS score, no CISA KEV entry, and no standalone exploit were provided; the referenced PR #51137 contains the fix plus validation unit tests but not a weaponized POC, so this is 'no public exploit identified at time of analysis.' The high CVSS score is driven by ease of the network-facing DoS, but real-world priority is materially narrowed because exploitation requires a prefill/decode disaggregated deployment (a non-default, advanced serving topology), so this is a high-CVSS/moderate-real-risk issue for most operators and a genuine availability concern only for the subset running P/D disaggregation with exposed completion endpoints.

An attacker who can reach a vLLM OpenAI-compatible /v1/completions or /v1/chat/completions endpoint of a prefill/decode disaggregated deployment sends a normal-looking request whose kv_transfer_params includes an enormous tp_size (e.g. 20,000,000). vLLM fails to validate the value and attempts a correspondingly huge memory allocation, exhausting RAM and causing the kernel to OOM-kill the decode worker, taking down inference. No exploit code is public, but the fix PR's tests demonstrate the exact malicious payload, and the network-facing, unauthenticated, low-complexity nature makes it trivial to reproduce.