GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: out-of-vocabulary stop_token_ids crash the engine and write past the V2 runner logits buffer

CVSS 7.1CVE-2026-116181AI/ML frameworks & servingcurated

Impact

Any client allowed to submit a request to a vLLM server can terminate the engine process by passing stop_token_ids outside the model vocabulary, and on the V2 runner the same input writes outside the logits buffer. On a GPU node this takes down the whole serving replica, not one request: the engine holds the model in device memory, so a restart means reloading weights and a cold-start window for every tenant sharing that replica. Repeated requests make the denial of service persistent. The out-of-bounds write is in GPU-adjacent buffers, so memory corruption of in-flight state cannot be ruled out, though the advisory claims no confidentiality or integrity impact.

Who can reach it

Any authenticated caller of the chat, completion, generate or batch endpoints - the CVSS vector requires low privileges, meaning an ordinary API user, reachable over the network. No operator access to the node is needed.

What to do

Upgrade vLLM to 0.29.0 or later and restart each serving process; model weights reload on restart, so schedule it per replica to keep capacity. No kernel or firmware work is involved. Until then, validate or clamp stop_token_ids at the gateway in front of vLLM.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-116181https://github.com/vllm-project/vllm/security/advisories/GHSA-w9r6-29q4-pvprhttps://www.vulncheck.com/advisories/vllm-0.20.1-before-0.29.0-dos-and-gpu-out-of-bounds-write-via-stop-token-ids

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.