vLLM: rejected requests leak decode-worker metadata until the worker exhausts memory

CVSS 8.7CVE-2026-93436AI/ML frameworks & servingcurated

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

https://nvd.nist.gov/vuln/detail/CVE-2026-93436 https://github.com/vllm-project/vllm/pull/55677 https://www.vulncheck.com/advisories/vllm-through-0.29.0-memory-exhaustion-via-rejected-requests https://github.com/vllm-project/vllm/blob/v0.29.0/vllm/distributed/kv_transfer/kv_connector/v1/nixl/push_worker.py#L162-L181

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.