vLLM CVE-2026-93436: Missing Cleanup of Decode-Side Metadata Exhausts Memory in Disaggregated Prefill/Decode Deployments

TL;DR — 90 seconds

vLLM does not clean up metadata for rejected requests in deployments with separated prefill and decode phases. A single request with max_tokens=0 makes the _recving_metadata structure on decode workers grow without bound until memory is exhausted and the worker restarts. No credentials are required, and the attack vector is the network. Affected are vLLM versions up to 0.29.0 with NIXL-based disaggregated prefill/decode enabled. An official fix is in progress (PR #55677) but not yet merged or released. Anyone running this deployment mode should filter requests with max_tokens=0 upfront and monitor decode-worker memory usage.

What is the problem?

vLLM supports a deployment mode where the prefill and decode phases of a language-model request run on separate workers (disaggregated prefill/decode), connected via the NIXL transport for key-value caches. When a request is rejected on the decode side before it is fully scheduled, empty receive operations remain in the worker's _recving_metadata metadata dictionary without ever being completed or cleaned up.

An attacker with access to the inference API can deliberately send requests with max_tokens=0. vLLM rejects these, but each rejection leaves another entry in the metadata dictionary. Repeated often enough, this grows the decode worker's memory usage without bound until the process has to be restarted. Affected are the paths through /v1/completions, /v1/chat/completions, and direct engine abort_immediately calls with remote prefill enabled.

Who is affected?

Affected are vLLM deployments that use the experimental NIXL-based prefill/decode disaggregation and expose their inference endpoints to untrusted requests.

Standard deployments without prefill/decode disaggregation enabled do not use the affected code path and are not directly affected. What also matters is whether the inference endpoints are reachable from an untrusted network.

Impact

An attacker with network access to the affected endpoints can inflate a decode worker's memory without bound, without credentials and without user interaction. The result is a denial of service: the worker process crashes or has to be restarted manually, interrupting other users' in-flight inference requests.

Confidentiality and integrity of the processed data are not affected as far as is currently known. The risk is limited to the availability of the inference infrastructure, which can still be significant for production LLM services with users or downstream systems depending on them.

Mitigation / Immediate actions

No fixed version had been announced at the time of writing. PR #55677 addresses the problem in push_worker.py and pull_worker.py, but is still awaiting a rebase and sign-off from the code owners.

Until a fix is released: filter requests with max_tokens=0 at an upstream reverse proxy or API gateway before they reach vLLM. Restrict access to inference endpoints with prefill/decode disaggregation enabled to trusted networks or authenticated callers. Consider an automated restart/watchdog mechanism for decode workers that detects abnormal memory growth and restarts the process in a controlled way before memory is fully exhausted.

Detection / Verification

Continuously monitor the memory usage of your decode-worker processes. A steady increase that cannot be explained by actual request load is a strong indicator of exploitation. Where possible, check the size of the internal _recving_metadata structure during load spikes with many aborted requests.

Review access logs for repeated requests with max_tokens: 0 in the request body, especially when they arrive from a single source in quick succession. A pattern of many rejected requests immediately before a worker restart confirms exploitation has already occurred.

Operator recommendation

Act today if: you run vLLM with prefill/decode disaggregation enabled and the inference endpoints are reachable from a network that is not fully trusted. Filter max_tokens=0 requests immediately and set up memory monitoring with alerting.

Monitoring is enough if: you run vLLM without prefill/decode disaggregation, or the affected endpoints are reachable only from a trusted internal network. Track the progress of PR #55677 and schedule the update once a fixed version is released.

Conclusion

This case shows a familiar pattern in new, functionally complex LLM-serving architectures. Separating prefill and decode phases brings performance benefits, but also introduces new states that are easily overlooked when designing error handling. Until the official fix lands, filtering at the edge of the infrastructure remains the most effective mitigation.

Sources

• VulnCheck: vLLM through 0.29.0 Memory Exhaustion via Rejected Requests
• GitHub: vllm-project/vllm PR #55677 (fix, open)
• NixOS/nixpkgs Issue #564522
• Strix: CVE-2026-93436