vllm EUVD-2026-31810

The OpenAI-compatible serving path must be enabled (vllm's default when launched with --served-model-name or equivalent API server mode). The attack requires sending a valid API request with the logprobs field set to -1 (full vocabulary) or a very large integer, combined with a high n value for parallel completions. No authentication is required per CVSS PR:N. Exploitation is limited to the v1 scheduler code path - deployments using the legacy v0 engine may not be affected, though this is not confirmed from available data. Air-gapped deployments or those behind an authenticated API gateway significantly reduce exposure. The condition limiting worst-case impact is that vllm is typically deployed with GPU memory constraints that bound how many simultaneous OOM-triggering requests can be processed before the server already enters a degraded state.

The CVSS 4.0 score of 5.5 with vector AV:N/AC:L/AT:N/PR:N/UI:N reflects moderate severity but understates operational risk for publicly exposed vllm deployments. The attack requires zero privileges, zero user interaction, and imposes no complexity barrier - any client with API access can trigger it. SSVC classifies this as Automatable:yes, meaning it can be reliably scripted at scale against exposed endpoints. The VA:L (low availability impact on the vulnerable system) rating may be conservative given the PR description explicitly cites OOM conditions as the failure mode, not merely latency. EPSS at 0.06% (18th percentile) is low, consistent with a niche ML infrastructure component rather than a broadly deployed consumer product. No KEV listing confirms no mass exploitation observed. The primary risk is targeted disruption of AI serving infrastructure - a single malicious request with logprobs=-1 and high n can monopolize GPU scheduler resources. Risk is substantially higher for publicly Internet-exposed vllm instances than for air-gapped or access-controlled deployments.

An attacker with network access to a publicly exposed vllm OpenAI-compatible endpoint submits a crafted /v1/completions or /v1/chat/completions request with logprobs=-1 (full vocabulary) and a high n value (many parallel completions). The v1 scheduler, lacking any logprob budget, computes the cost as n × vocab_size (potentially millions), allocates the corresponding memory and GPU compute, causing OOM errors or complete latency stalls that render the inference server unresponsive. Publicly available exploit code exists in GitHub issue #37343, lowering the bar for reproduction to near-zero.