CVE-2026-92220: vLLM: MoRIIO KV handler flaw allows remote DoS

MEDIUM
Published September 16, 2026
CISO Take

A flaw in vLLM 0.26.0/0.27.0's MoRIIO KV-transfer acknowledgement handler lets a remote, unauthenticated attacker manipulate request_id or kv_transfer_params to exhaust resources and degrade inference availability. Severity is medium (CVSS 5.3, availability-only impact), EPSS is low at 0.007 (top 48%), and the CVE is not in CISA KEV, has no public exploit or Nuclei template, and carries a CISA SSVC decision of TRACK. The practical risk is concentrated in organizations running disaggregated or multi-node vLLM serving with the MoRIIO connector enabled and reachable from untrusted networks; default single-node deployments are unlikely to be exposed. The maintainers have not yet responded to the fix pull request (vllm-project/vllm#50674), so no official patched release exists. Check whether the MoRIIO KV connector is enabled, restrict network access to KV-transfer endpoints, and monitor the upstream PR for a fix.

Sources:NVDEPSSATLASGitHub (vllm-project PR #50674)VulDB

What is the risk?

Low-to-medium risk. The attack is network-reachable, low complexity, and needs no privileges or user interaction, but the impact is limited to availability (A:L) with no confidentiality or integrity effect. EPSS is low, there is no known exploitation, no public exploit, and SSVC says TRACK. Exposure depends on the MoRIIO connector being enabled, which is a non-default and specialized KV-transfer configuration. The lack of a vendor response raises the risk of a prolonged unpatched window.

How does the attack unfold?

Initial Access
Attacker reaches a network-exposed vLLM node with the MoRIIO KV connector enabled.
AML.T0049
Exploitation
Crafted request_id or kv_transfer_params values are sent to the MoRIIO acknowledgement handler.
AML.T0049
Resource Exhaustion
Request state and KV resources are not properly released, accumulating consumption over repeated requests.
AML.T0034
Impact
Inference service slows or crashes, denying availability to dependent AI applications.
AML.T0029

What systems are affected?

PackageEcosystemVulnerable RangePatched
vLLMpip—No patch
96.0K94 dependentsPushed 5d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1
5.3 / 10
EPSS
0.7%
chance of exploitation in 30 days
Higher than 53% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACLow
PRNone
UINone
SUnchanged
CNone
INone
ALow

What should I do?

1 step
  1. 1) Inventory vLLM deployments running 0.26.0 or 0.27.0 and identify any that configure the MoRIIO KV connector. 2) Track vllm-project/vllm PR #50674 and upgrade as soon as a patched release ships; consider applying the PR as a local patch after review. 3) Until patched, disable the MoRIIO connector where it is not required. 4) Restrict KV-transfer and inter-node ports to trusted internal segments using network policies, firewalls, or service mesh mTLS. 5) Monitor for abnormal growth in GPU/host memory, KV cache occupancy, pending or unreleased request counts, and spikes in malformed kv_transfer_params. 6) Set resource limits, health-check-based restarts and autoscaling to contain impact.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableYes
Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15-Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.6-AI system operation and monitoring
NIST AI RMF
MANAGE 2.3-Responses to previously unknown risks and mechanisms to supersede or deactivate AI systems
OWASP LLM Top 10
LLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-92220?

A flaw in vLLM 0.26.0/0.27.0's MoRIIO KV-transfer acknowledgement handler lets a remote, unauthenticated attacker manipulate request_id or kv_transfer_params to exhaust resources and degrade inference availability. Severity is medium (CVSS 5.3, availability-only impact), EPSS is low at 0.007 (top 48%), and the CVE is not in CISA KEV, has no public exploit or Nuclei template, and carries a CISA SSVC decision of TRACK. The practical risk is concentrated in organizations running disaggregated or multi-node vLLM serving with the MoRIIO connector enabled and reachable from untrusted networks; default single-node deployments are unlikely to be exposed. The maintainers have not yet responded to the fix pull request (vllm-project/vllm#50674), so no official patched release exists. Check whether the MoRIIO KV connector is enabled, restrict network access to KV-transfer endpoints, and monitor the upstream PR for a fix.

Is CVE-2026-92220 actively exploited?

No confirmed active exploitation of CVE-2026-92220 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-92220?

1) Inventory vLLM deployments running 0.26.0 or 0.27.0 and identify any that configure the MoRIIO KV connector. 2) Track vllm-project/vllm PR #50674 and upgrade as soon as a patched release ships; consider applying the PR as a local patch after review. 3) Until patched, disable the MoRIIO connector where it is not required. 4) Restrict KV-transfer and inter-node ports to trusted internal segments using network policies, firewalls, or service mesh mTLS. 5) Monitor for abnormal growth in GPU/host memory, KV cache occupancy, pending or unreleased request counts, and spikes in malformed kv_transfer_params. 6) Set resource limits, health-check-based restarts and autoscaling to contain impact.

What systems are affected by CVE-2026-92220?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference clusters, disaggregated prefill/decode serving, distributed KV cache transfer.

What is the CVSS score for CVE-2026-92220?

CVE-2026-92220 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.70%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference clustersdisaggregated prefill/decode servingdistributed KV cache transfer

MITRE ATLAS Techniques

AML.T0029Denial of AI Service
AML.T0034Cost Harvesting
AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15
ISO 42001: A.6.2.6
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM10

What are the technical details?

Original Advisory

A vulnerability was found in vllm-project vLLM 0.26.0/0.27.0. Affected is the function MoRIIOConnectorScheduler.request_finished/MoRIIOConnectorWorker.get_finished/MoRIIOWrapper._handle_release_message of the file vllm/distributed/kv_transfer/kv_connector/v1/moriio/moriio_connector.py of the component MoRIIO Acknowledgement Handler. Performing a manipulation of the argument request_id/kv_transfer_params results in resource consumption. It is possible to initiate the attack remotely. The project was informed of the problem early through a pull request but has not reacted yet.

Exploitation Scenario

An attacker locates a vLLM cluster whose MoRIIO KV-transfer acknowledgement endpoint is reachable from an exposed or poorly segmented network. They send crafted release/acknowledgement messages with manipulated request_id or kv_transfer_params values, causing the handler to leak or never free request state and consume memory or KV cache. Repeated requests progressively degrade inference capacity until the serving nodes slow down, time out, or crash, disrupting dependent AI applications.

Weaknesses (CWE)

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

  • [Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • [Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Timeline

Published
September 16, 2026
Last Modified
September 16, 2026
First Seen
September 16, 2026

Related Vulnerabilities