GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: unbounded prompt array in /v1/completions lets one request exhaust the engine

CVSS 6.5CVE-2026-73559AI/ML frameworks & servingcurated

Impact

The CompletionRequest.prompt field accepts an unbounded list of strings or token-id lists, and the serving path creates one engine generator and one response slot per element. A single accepted request can therefore consume all request slots, CPU, host memory and async scheduling capacity on the replica, stalling or dropping every other tenant's inference on that GPU. On a shared inference node this is a cheap way for one API client to take the accelerator out of service for everyone behind the same endpoint, and recovery means restarting the server and reloading model weights. No data disclosure is described - the effect is availability only.

Who can reach it

Any client that can authenticate to the vLLM OpenAI-compatible HTTP endpoint (an API key, or network reach where the endpoint is deployed without auth). No special privileges beyond ordinary inference access.

What to do

Upgrade to vLLM 0.26.0 and restart each serving process; that drops in-flight requests and re-loads model weights on every replica, so roll it replica by replica behind the load balancer. Until then, cap request body size and reject oversized prompt arrays at the gateway in front of vLLM. Affected from 0.19.0 up to 0.26.0.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73559https://github.com/vllm-project/vllm/security/advisories/GHSA-87x5-vmc3-756jhttps://github.com/vllm-project/vllm/commit/675f4295cdfe0d870471c2b51bfeca3a68a9569ehttps://github.com/vllm-project/vllm/releases/tag/v0.26.0

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.