Database/AI/ML frameworks & serving
vLLM: rejected requests leak decode-worker metadata until the worker exhausts memory
Impact
In prefill/decode disaggregated deployments vLLM does not clean up decode-side metadata for requests it rejects, so a client that submits requests with max_tokens=0 grows worker memory without bound until the process dies or is restarted. The requests are cheap to send and are rejected, so ordinary request accounting and token quotas do not see them. On a GPU node this takes out the decode workers holding the KV cache for live sessions, and the GPUs stay idle for the duration of the restart. Confidentiality and integrity are unaffected - this is availability only.
Who can reach it
Any client that can reach the vLLM API endpoint; the record indicates no authentication is needed, so in practice any tenant or anything on the network path to the inference endpoint.
What to do
Affected through 0.29.0; the fix is upstream PR 55677 - upgrade to a release that contains it once published, then restart the affected vLLM workers. In the meantime reject or normalize max_tokens=0 at the gateway in front of vLLM and alert on decode-worker RSS growth. Remediation is a serving-process restart per node, not a reboot.
References
Related entries
- vLLM: negative token IDs in embeddings requests poison the CUDA context and wedge the engineCVE-2026-93592 · vLLM (/v1/embeddings and /pooling token ID validation)High
- vLLM: incomplete NIXL kv_transfer_params kills the decode engine with an uncaught KeyErrorCVE-2026-94622 · vLLM NIXL KV connector (kv_transfer_params metadata handling)High
- vLLM: multi-prompt completion request trips a NIXL prefix-caching assertion and kills the decode workerCVE-2026-94623 · vLLM NIXL connector prefix caching (NixlBaseConnectorWorker._apply_prefix_caching)High
- vLLM: attacker-chosen P2P offload peers exhaust ZeroMQ contexts and crash EngineCoreCVE-2026-94624 · vLLM P2P KV offloading (OffloadingConnector TieringOffloadingSpec, ZeroMQ control)High
- vLLM: unvalidated tp_size in kv_transfer_params drives the decode worker into OOM-killCVE-2026-94626 · vLLM NIXL KV connector (unvalidated tp_size in kv_transfer_params)High
- vLLM: Mooncake transfer-ID collision leaks GPU KV cache blocks until restartCVE-2026-94627 · vLLM Mooncake KV connector (transfer-ID ownership of GPU KV cache blocks)High
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.