The vulnerability stems from a lack of bounds checking on stop_token_ids supplied to the Rust HTTP or gRPC front‑end of vLLM. Attackers can send a request containing a min_tokens value greater than zero together with token identifiers that are outside the model’s vocabulary range. Those out‑of‑range IDs reach the MinTokensLogitsProcessor, which performs CUDA tensor indexing without protecting against invalid indices, leading to a crash of the EngineCore. The result is a denial of service because the engine enters a fatal state that only a service restart can recover from. This flaw is an input validation weakness (CWE‑20) and an improper bounds check (CWE‑1285).

The issue affects vLLM versions 0.22.0 through 0.23.0, as maintained by the vllm‑project. The vulnerability is present in both the Rust HTTP and gRPC front‑ends that expose the inference API. Any deployment of these versions that allows external clients to provide stop_token_ids is susceptible, regardless of the model being served.

The CVSS score of 8.2 indicates a high impact, and the lack of an EPSS entry suggests that exploitation probability is currently unknown but should be treated as significant in a high‑traffic setting. The vulnerability can be triggered remotely by an attacker who can reach the inference API, and no privileged user state is required. Although the vulnerability is not listed in the CISA KEV catalog, the potential to bring the engine to a fatal state makes rapid response advisable.