CVE-2026-94622: vLLM NIXL KeyError crashes decode

CISO Take

CVE-2026-94622 is an unauthenticated denial-of-service flaw in vLLM through 0.29.0: a request with an incomplete kv_transfer_params dictionary triggers an uncaught KeyError in the NIXL connector, which terminates the decode engine in prefill/decode disaggregated deployments. All routed requests then fail until someone restarts it manually, so a single crafted request can take down an inference tier. Exploitation is easy (network-reachable, low complexity, no privileges, CVSS 7.5), but there is no public exploit, no Nuclei template, no KEV listing, and EPSS is low at 0.00627 (around the 52nd percentile); CISA SSVC says TRACK. The exposure is limited to teams running disaggregated serving with the NIXL connector, which is common in large-scale or latency-sensitive deployments. Upgrade to a vLLM release that includes the fix from PR 54807, and until then keep the API and any client-controlled kv_transfer_params away from untrusted users. Also put automatic restarts and alerting on decode engine exits.

Sources:NVDEPSSCISA SSVCATLASVulnCheckGitHub (vllm-project/vllm)

What is the risk?

Rated high on severity but moderate in practice. The attack is network-based, needs no authentication or user interaction and has low complexity, with impact limited to availability (A:H, C:N, I:N). Likelihood is tempered by the lack of a public exploit or scanner template, the low EPSS (0.00627), no KEV listing and a TRACK decision from SSVC. Exposure depends on whether untrusted callers can reach the API with kv_transfer_params passed through, and on whether the NIXL connector in a prefill/decode disaggregated setup is in use. Deployments with a default single-node vLLM setup are not affected by this code path. Confidence: HIGH on the technical mechanism (vendor code references and the VulnCheck advisory), MEDIUM on real-world exposure because Affected Products and dependent counts are not listed.

How does the attack unfold?

Initial Access

Attacker reaches the vLLM API or router in a prefill/decode disaggregated deployment with no authentication required.

AML.T0049

Exploitation

Attacker sends a request with an incomplete kv_transfer_params dictionary, triggering an uncaught KeyError in the NIXL metadata handling.

AML.T0040

Impact

EngineCore scheduling fails, the decode engine terminates, and all routed requests fail until manual restart.

AML.T0029

Initial Access

Attacker reaches the vLLM API or router in a prefill/decode disaggregated deployment with no authentication required.

AML.T0049

Exploitation

Attacker sends a request with an incomplete kv_transfer_params dictionary, triggering an uncaught KeyError in the NIXL metadata handling.

AML.T0040

Impact

EngineCore scheduling fails, the decode engine terminates, and all routed requests fail until manual restart.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	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

7.5 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 50% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to a release later than 0.29.0 that includes the fix from PR 54807 (https://github.com/vllm-project/vllm/pull/54807); verify the version in container images and lock files. 2) Until patched, do not expose the vLLM OpenAI-compatible API directly to untrusted clients; place a gateway or proxy in front that strips or validates kv_transfer_params and rejects requests with unexpected keys. 3) Restrict network access to the decode and prefill engines to trusted routers only. 4) Configure supervisor or orchestrator restarts (Kubernetes liveness probes, restart policies) so a crash does not need manual intervention. 5) Detection: alert on unexpected EngineCore or decode process exits, KeyError tracebacks in the NIXL metadata path, and spikes of 5xx responses from the routing layer; log and review requests containing kv_transfer_params from external sources. 6) Rate-limit and authenticate API access with per-client keys.

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?

DoSInferenceFrameworkAML.T0029- Denial of AI Service AML.T0040- AI Model Inference API Access AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Procedures to respond to and recover from unknown risks

OWASP LLM Top 10

LLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-94622?

CVE-2026-94622 is an unauthenticated denial-of-service flaw in vLLM through 0.29.0: a request with an incomplete kv_transfer_params dictionary triggers an uncaught KeyError in the NIXL connector, which terminates the decode engine in prefill/decode disaggregated deployments. All routed requests then fail until someone restarts it manually, so a single crafted request can take down an inference tier. Exploitation is easy (network-reachable, low complexity, no privileges, CVSS 7.5), but there is no public exploit, no Nuclei template, no KEV listing, and EPSS is low at 0.00627 (around the 52nd percentile); CISA SSVC says TRACK. The exposure is limited to teams running disaggregated serving with the NIXL connector, which is common in large-scale or latency-sensitive deployments. Upgrade to a vLLM release that includes the fix from PR 54807, and until then keep the API and any client-controlled kv_transfer_params away from untrusted users. Also put automatic restarts and alerting on decode engine exits.

Is CVE-2026-94622 actively exploited?

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

How to fix CVE-2026-94622?

1) Upgrade vLLM to a release later than 0.29.0 that includes the fix from PR 54807 (https://github.com/vllm-project/vllm/pull/54807); verify the version in container images and lock files. 2) Until patched, do not expose the vLLM OpenAI-compatible API directly to untrusted clients; place a gateway or proxy in front that strips or validates kv_transfer_params and rejects requests with unexpected keys. 3) Restrict network access to the decode and prefill engines to trusted routers only. 4) Configure supervisor or orchestrator restarts (Kubernetes liveness probes, restart policies) so a crash does not need manual intervention. 5) Detection: alert on unexpected EngineCore or decode process exits, KeyError tracebacks in the NIXL metadata path, and spikes of 5xx responses from the routing layer; log and review requests containing kv_transfer_params from external sources. 6) Rate-limit and authenticate API access with per-client keys.

What systems are affected by CVE-2026-94622?

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

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

CVE-2026-94622 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.63%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inferenceprefill/decode disaggregated servingdistributed KV cache transfer

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0040AI Model Inference API Access

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 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

vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for prefill/decode disaggregated deployments. Attackers can send requests with incomplete kv_transfer_params dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, causing the decode engine to terminate and making all routed requests fail until manual restart.

Exploitation Scenario

An attacker finds an internet- or partner-reachable vLLM endpoint behind a router that fronts a disaggregated prefill/decode cluster using NIXL. They send a chat or completion request whose kv_transfer_params dictionary omits required entries. The decode engine hits the uncaught KeyError during EngineCore scheduling and exits. Every request routed to that decode engine now fails, and the attacker can repeat the request each time the service is manually restarted, keeping the LLM service down at almost no cost.

Weaknesses (CWE)

CWE-248Uncaught ExceptionPrimary CWE-248Uncaught Exception

CWE-248 — Uncaught Exception: An exception is thrown from a function, but it is not caught.

[Requirements] The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem.
[Requirements] A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added.

Source: MITRE CWE corpus.