Summary
vLLM: Out-of-vocabulary prompt token id passes input validation and triggers a CUDA device-side assert (engine crash / DoS)
For a model whose vocabulary size is an exact multiple of the embedding padding size (64), e.g. any Llama-2-family model, vocab 32000, a single request carrying a pre-tokenized prompt with token id equal to the vocab size (32000) passes vLLM's input-id validation but is one past the last embedding row. At tensor-parallel size 1 the embedding lookup does not mask indices, so the id reaches F.embedding out of range and raises a CUDA device-side assert, which poisons the engine's CUDA context and takes the engine down. Any client that can send pre-tokenized input (/v1/completions with prompt as token ids, /tokenize-fed flows, or the kv_transfer_params["prompt_token_ids"] reuse path) can trigger it.
Root cause
vllm/v1/engine/input_processor.py accepts a token id when id <= max(tokenizer.max_token_id, model_config.get_vocab_size() - 1).vllm/tokenizers/hf.py computes max_token_id = max(max(vocab.values()), tokenizer.vocab_size). For Llama-2 tokenizers max(vocab.values()) = 31999 but tokenizer.vocab_size = 32000, so max_token_id = 32000, one greater than the largest valid id.
The engine bound therefore becomes max(32000, 31999) = 32000, and id 32000 is accepted.
The model's embedding has pad_vocab_size(32000, 64) = 32000 rows (no padding), valid indices 0..31999. At VocabParallelEmbedding.forward with tp_size == 1 there is no masking, so index 32000 hits F.embedding out of range.
Affected
- tp=1 (single GPU per model, common per-copy layout). tp>1 masks via
get_masked_input_and_mask, so the id is clamped, not an OOB, likely wrong output rather than a crash. - Models whose vocab is a multiple of 64 with
tokenizer.vocab_sizeone past the max real id (Llama-2 family, vocab 32000, is the clear case). Qwen2.5 is NOT affected (padded headroom).
Reporter
Shijie Lyu (GitHub shijie-lyu [email protected]). Reported privately per SECURITY.
This advisory was fixed in MR59491.
Impact
CVE-2026-115916 has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.32.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
max_token_id in vllm/tokenizers/hf.py now uses tokenizer.vocab_size - 1, so an id equal to the vocabulary size fails input validation instead of reaching the embedding. Fixed in MR59491, released in v0.32.0.
Frequently Asked Questions
- What is CVE-2026-115916? CVE-2026-115916 is a medium-severity security vulnerability in vllm (pip), affecting versions < 0.32.0. It is fixed in 0.32.0.
- How severe is CVE-2026-115916? CVE-2026-115916 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of vllm are affected by CVE-2026-115916? vllm (pip) versions < 0.32.0 is affected.
- Is there a fix for CVE-2026-115916? Yes. CVE-2026-115916 is fixed in 0.32.0. Upgrade to this version or later.
- Is CVE-2026-115916 exploitable, and should I be worried? Whether CVE-2026-115916 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-115916 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-115916? Upgrade
vllmto 0.32.0 or later.