CVE-2026-92220: vLLM MoRIIO DoS Vulnerability

CVE-2026-92220 Overview

CVE-2026-92220 is a resource consumption vulnerability affecting vLLM versions 0.26.0 and 0.27.0. The flaw resides in the MoRIIO Acknowledgement Handler component, specifically within the MoRIIOConnectorScheduler.request_finished, MoRIIOConnectorWorker.get_finished, and MoRIIOWrapper._handle_release_message functions inside vllm/distributed/kv_transfer/kv_connector/v1/moriio/moriio_connector.py. Attackers can manipulate the request_id or kv_transfer_params arguments to trigger uncontrolled resource consumption. The vulnerability is exploitable remotely over the network without authentication or user interaction. The vLLM project was notified through a pull request but has not yet responded with a fix.

Critical Impact
Remote unauthenticated attackers can degrade availability of vLLM inference servers by manipulating request identifiers and key-value transfer parameters, exhausting distributed KV-cache resources.

Affected Products

vllm-project vLLM 0.26.0
vllm-project vLLM 0.27.0
Deployments using the MoRIIO KV transfer connector for distributed inference

Discovery Timeline

2026-09-16 - CVE-2026-92220 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-92220

Vulnerability Analysis

vLLM is a high-throughput inference and serving engine for large language models (LLMs). Distributed deployments use a key-value (KV) cache transfer layer to move attention state between worker processes. The MoRIIO connector implements this transfer along with an acknowledgement handler that tracks completion of in-flight requests.

The vulnerable functions accept attacker-influenced identifiers and transfer parameters without enforcing bounds or lifecycle validation. Requests referencing fabricated or duplicated request_id values, or oversized kv_transfer_params payloads, cause the acknowledgement handler to allocate and retain memory or scheduler state indefinitely. Repeated abuse degrades the throughput of the inference server and can render it unresponsive to legitimate traffic. The weakness is classified as uncontrolled resource consumption [CWE-400].

Root Cause

The scheduler and worker paths in moriio_connector.py treat incoming request_id and kv_transfer_params values as trusted inputs. There is no validation that a request_id corresponds to an in-flight request tracked by the scheduler, and no upper bound is enforced on the parameters passed to the release-message handler. Bookkeeping state accumulates for every crafted request, and release messages tied to non-existent requests are not discarded cleanly.

Attack Vector

An attacker with network reachability to a vLLM deployment running the MoRIIO connector can send crafted inference or KV-transfer requests. By repeatedly submitting messages with unique or malformed request_id values, or with inflated kv_transfer_params, the attacker forces the acknowledgement handler to consume memory and scheduler queue capacity. No authentication or user interaction is required. Publicly reachable inference endpoints are the primary exposure.

A verified proof-of-concept exploit is not publicly available. See the GitHub Pull Request #50674 for technical details on the proposed fix.

Detection Methods for CVE-2026-92220

Indicators of Compromise

Sustained growth in vLLM worker memory or scheduler queue depth without a corresponding increase in completed inference requests.
High volumes of KV-transfer release messages referencing request_id values that were never scheduled.
Latency spikes or timeouts on inference endpoints correlated with bursts of connector traffic.

Detection Strategies

Instrument the MoRIIO connector paths with metrics on in-flight request counts, acknowledgement queue length, and per-request memory footprint.
Alert when the ratio of release messages to completed requests exceeds a baseline threshold, indicating fabricated request_id traffic.
Log and rate-limit clients issuing high frequencies of KV-transfer messages against the same worker.

Monitoring Recommendations

Track process resident memory and Python heap size for vLLM workers over time, with alerts on unbounded growth.
Monitor network telemetry for unusual source addresses posting to inference or KV-transfer endpoints.
Correlate application logs from moriio_connector.py with system-level resource utilization to surface early exhaustion patterns.

How to Mitigate CVE-2026-92220

Immediate Actions Required

Restrict network access to vLLM inference and KV-transfer endpoints using firewalls, service mesh policies, or private networking.
Place vLLM servers behind an authenticating reverse proxy or API gateway that enforces per-client rate limits.
Disable the MoRIIO connector in deployments that do not require distributed KV transfer between workers.
Monitor the vLLM GitHub repository for a patched release addressing the connector logic.

Patch Information

At the time of publication, the vLLM project has not released an official patch. A fix has been proposed via GitHub Pull Request #50674 but has not been merged. Additional tracking is available through VulDB CVE-2026-92220. Operators should track the pull request and upgrade as soon as a fixed release is published.

Workarounds

Deploy vLLM instances only on trusted, segmented networks with strict ingress controls.
Enforce authentication and per-source rate limiting at the ingress layer to bound the volume of request identifiers a single client can generate.
Configure container or cgroup memory limits on vLLM workers so that resource exhaustion triggers a controlled restart rather than host-wide degradation.
Prefer alternative KV-transfer connectors until the MoRIIO acknowledgement handler is patched.

bash

# Example: restrict vLLM API exposure with iptables and enforce a memory ceiling
# Allow only trusted subnet to reach the vLLM API port
iptables -A INPUT -p tcp --dport 8000 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP

# Run the vLLM container with a hard memory limit
docker run --rm \
  --memory=32g --memory-swap=32g \
  --network=internal \
  -p 127.0.0.1:8000:8000 \
  vllm/vllm-openai:latest