GPU VulnDB

Database/AI/ML frameworks & serving

vLLM: unvalidated MoRIIO ack fields let a remote client exhaust resources on a serving node

CVSS 6.9CVE-2026-92220AI/ML frameworks & servingcurated

Impact

The MoRIIO KV-transfer connector in vLLM 0.26.0/0.27.0 accepts attacker-controlled request_id and kv_transfer_params values in its acknowledgement/release path, and manipulation leads to uncontrolled resource consumption on the serving process. On a GPU node this is availability damage where it hurts most: the engine holds the GPUs, so a wedged or memory-starved vLLM process idles expensive accelerators until it is restarted, and a disaggregated prefill/decode deployment exposes the connector between pods rather than only to a single trusted caller. The record reports availability impact only - no confidentiality or integrity loss. The project was notified through a pull request and, per the record, had not shipped a fix at publication.

Who can reach it

Remote, no authentication stated, for anyone who can reach the vLLM MoRIIO connector endpoint - in practice any workload on the network segment carrying KV transfer traffic between prefill and decode workers.

What to do

No fixed release is named in the record; PR vllm-project/vllm#50674 is the proposed fix and had not been merged. Until a release lands, keep MoRIIO KV transfer off unless it is needed, and restrict the connector's network reachability to the serving pods that must speak it. Applying a fix once released means restarting the vLLM engine, which drops in-flight requests and reloads model weights onto the GPUs - schedule it like any serving-daemon restart.

References

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.