CVE-2026-92220: vLLM: MoRIIO KV handler flaw allows remote DoS
MEDIUMA 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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) 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?
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:
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
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034Cost HarvestingAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
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-400Uncontrolled Resource ConsumptionPrimaryCWE-404Improper Resource Shutdown or ReleasePrimaryCWE-400Uncontrolled Resource ConsumptionCWE-404Improper Resource Shutdown or ReleaseCWE-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:LReferences
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm