A rejected request with max_tokens=0 exhausts decode-worker memory in disaggregated vLLM

What happened

vLLM fails to clean up decode-side metadata for rejected requests in disaggregated setups, so a remote attacker submitting max_tokens=0 grows decode-worker memory until the worker restarts. Scored CVSS 3.1 7.5. The fix pull request was still open and unmerged when the record published on 17 September, so no patched version exists yet.

The request is rejected, but the decode worker has already allocated for it and never frees the allocation. Deployments that split prefill and decode across workers are the exposed shape; single-process serving is unaffected.