CVE-2026-115916Medium· 6.5▾ SunlitvLLM: Out-of-vocabulary prompt token id passes input validation and triggers a CUDA device-side assert (engine crash / DoS)
▾ Sunlit zone — Low / medium · no exploitation signal
impact 35.8 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Oct 27.
Disclosure to exploitation, from the record and what we observed since indexing it.
0.3%
Disclosed via OSV
Last analysed / modified upstream
0.3% → 0.3%
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.
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.
get_masked_input_and_mask, so the id is clamped, not an OOB — likely wrong output rather than a crash.tokenizer.vocab_size one past the max real id (Llama-2 family, vocab 32000, is the clear case). Qwen2.5 is NOT affected (padded headroom).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.
Shijie Lyu (GitHub shijie-lyu [email protected]). Reported privately per SECURITY.
This advisory was fixed in MR59491.
vllm < 0.32.0Upgrade to a patched release:
vllm 0.32.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-115911Medium· 6.5vLLM: DoS via unbounded chat_template Jinja2 rendering exhausts the renderer thread pool
CVE-2026-115912High· 7.5vLLM: Public multimodal SHM handle forgery reaches worker-side `pickle.loads()` with insecure serialization disabled
CVE-2026-115913Medium· 6.5vLLM: Phi-4 multimodal audio encoder materializes and retains full attention matrices: a single max-length audio OOM-crashes the vLLM engine
CVE-2026-115917Low· 3.4vLLM: Permissive default CORS origins allow cross-origin requests to the vLLM HTTP server
CVE-2026-115915High· 8.1vLLM: Untrusted EPS inputs can trigger denial of service or Ghostscript RCE
CVE-2026-115914Medium· 6.5vLLM DeepSeek-OCR image processing vulnerable to denial of service