vLLM EUVD-2026-107002

Requires network reachability to the vLLM /inference/v1/generate endpoint on a server running a version before 0.31.0. The specific trigger is a single generate request that sets max_tokens to null (which causes the vulnerable code to SKIP the min_tokens <= max_tokens check) combined with an oversized min_tokens value; both conditions together produce the uncaught VLLMValidationError that kills the EngineCore input thread. Limiting/mitigating factors: the description claims unauthenticated access, but the vendor CVSS vector asserts PR:L (some authentication), so deployments that gate the inference API behind authentication or network ACLs materially reduce exposure; no user interaction is needed, and recovery requires a manual restart because /health falsely reports healthy.

This is a genuine availability-only denial-of-service flaw (CWE-248, Uncaught Exception), not a confidentiality/integrity issue - the CVSS 4.0 vector confirms VC:N/VI:N/VA:H, so the 7.1 score is driven entirely by the ability to take the service down. The attack vector is network (AV:N) with low complexity (AC:L) and no user interaction (UI:N), and the impact is amplified because a single malformed request permanently wedges the EngineCore input thread while /health keeps returning 200, meaning load balancers and orchestration health checks will NOT detect the outage and will not auto-restart the pod - this makes it meaningfully worse than a typical crash-DoS. There is a clear and important CONFLICT in the input: the description states 'Unauthenticated remote attackers' can trigger this, but the vendor-supplied CVSS 4.0 vector sets PR:L (privileges required / authenticated). This must be verified with the vendor/advisory before basing exposure decisions on it - if the endpoint is genuinely reachable without auth, real-world risk is higher than the 7.1 suggests. No EPSS score, no CISA KEV listing, and no public exploit were provided; exploitation probability signals are therefore absent rather than low, so the absence should not be read as 'safe.' Overall this is a real operational-availability priority for anyone exposing vLLM inference endpoints, tempered by the authentication ambiguity.

An attacker who can reach a vLLM server's /inference/v1/generate endpoint sends a single crafted request that omits max_tokens (null) and supplies an oversized min_tokens value, bypassing the min_tokens <= max_tokens validation; the EngineCore input thread then dies on an uncaught VLLMValidationError. Because /health continues to return 200, orchestration never restarts the process, and every subsequent generation request hangs until an operator manually restarts the service. No public exploit code was identified in the provided data, but the request is trivial to construct from the description.