The vulnerability is an improper validation of array indexes. vLLM versions before 0.29.0 accept user‑controlled stop_token_ids on the OpenAI‑compatible POST /v1/completions and POST /v1/chat/completions endpoints. The code checks only that the submitted values are integers, but does not verify that each token id lies within the vocabulary or logits range. When an attacker supplies an out‑of‑range id and min_tokens > 0, the service attempts to use that id as a logits index, triggering a CUDA indexing operation that fails with a device‑side assertion. The result is a 500 Internal Server Error that puts EngineCore into a fatal state. Subsequent requests fail until the service is restarted, effectively denying service.

Affected deployments are those running any vLLM version earlier than 0.29.0 from the vllm‑project. The flaw manifests through the OpenAI‑compatible API endpoints, so any client able to send a POST request to /v1/completions or /v1/chat/completions with a crafted stop_token_ids payload can trigger the issue. The vulnerability exists only in deployments that expose these endpoints and that are running the vulnerable code base. No specific hardware or cluster configurations are mentioned as prerequisites, but the crash involves a CUDA device, implying that the targeted environment uses GPU acceleration.

The CVSS score is 7.1 indicating a medium‑to‑high severity. EPSS is not available, and the weakness is not listed in CISA KEV. The attack requires an authenticated API user because the endpoint accepts authenticated requests. The design of the vulnerability means that a single malformed request can bring the entire EngineCore process down, making it an actionable denial‑of‑service vector. Based on the description, the likely attack vector is an authenticated internal API call. There is no evidence of additional credential or network exploitation required.