AI Threat AlertCVE-2026-94623: vLLM: NIXL multi-prompt assertion crash causes DoS
HIGHvLLM through 0.29.0 has an unauthenticated denial-of-service flaw in the NIXL connector used for prefill/decode disaggregated serving. A single network request containing multiple prompts of different lengths triggers an assertion failure that kills the decode worker until it is manually restarted. The CVSS score is 7.5 (availability impact only; no confidentiality or integrity loss). Real-world urgency is moderate: EPSS is 0.63% (top 52%), there is no public exploit, no Nuclei template, it is not in CISA KEV, and CISA SSVC says TRACK. Exposure is limited to teams running disaggregated prefill/decode with NIXL, so first inventory which clusters use that mode. Then apply the upstream fix (PR #51505) once it is released in a version above 0.29.0, and keep the completions endpoint behind authentication and rate limiting until then.
What is the risk?
Overall risk is medium-high for affected deployments and low for the general vLLM install base. The vulnerability is network-reachable, needs no privileges or user interaction, and has low complexity (CVSS 7.5), but it affects availability only. Exploitation likelihood is low-to-moderate: EPSS 0.00627, no known public exploit, no KEV listing, and SSVC TRACK. The risk rises sharply if the OpenAI-compatible API is exposed to untrusted networks or if the disaggregated decode tier is a single point of failure for a production inference service. The vulnerable code path only runs when the NIXL KV-transfer connector is enabled.
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 and identify those using the NIXL connector in disaggregated prefill/decode mode; versions up to and including 0.29.0 are affected. 2) Upgrade to a vLLM release that includes the fix from PR #51505 (https://github.com/vllm-project/vllm/pull/51505) as soon as one is available. 3) Until patched, place the completions API behind an authenticated gateway, restrict network access to trusted clients, and apply rate limiting. 4) Consider rejecting or normalizing completion requests that contain multiple prompts (batched prompt lists) at the gateway if the application does not need them. 5) Run decode workers under a supervisor (Kubernetes, systemd) with automatic restart and health checks, and add redundant decode replicas. 6) Detection: alert on decode worker crashes, AssertionError traces mentioning _apply_prefix_caching, repeated worker restarts, and unusual multi-prompt completion requests from a single source.
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-94623?
vLLM through 0.29.0 has an unauthenticated denial-of-service flaw in the NIXL connector used for prefill/decode disaggregated serving. A single network request containing multiple prompts of different lengths triggers an assertion failure that kills the decode worker until it is manually restarted. The CVSS score is 7.5 (availability impact only; no confidentiality or integrity loss). Real-world urgency is moderate: EPSS is 0.63% (top 52%), there is no public exploit, no Nuclei template, it is not in CISA KEV, and CISA SSVC says TRACK. Exposure is limited to teams running disaggregated prefill/decode with NIXL, so first inventory which clusters use that mode. Then apply the upstream fix (PR #51505) once it is released in a version above 0.29.0, and keep the completions endpoint behind authentication and rate limiting until then.
Is CVE-2026-94623 actively exploited?
No confirmed active exploitation of CVE-2026-94623 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-94623?
1) Inventory vLLM deployments and identify those using the NIXL connector in disaggregated prefill/decode mode; versions up to and including 0.29.0 are affected. 2) Upgrade to a vLLM release that includes the fix from PR #51505 (https://github.com/vllm-project/vllm/pull/51505) as soon as one is available. 3) Until patched, place the completions API behind an authenticated gateway, restrict network access to trusted clients, and apply rate limiting. 4) Consider rejecting or normalizing completion requests that contain multiple prompts (batched prompt lists) at the gateway if the application does not need them. 5) Run decode workers under a supervisor (Kubernetes, systemd) with automatic restart and health checks, and add redundant decode replicas. 6) Detection: alert on decode worker crashes, AssertionError traces mentioning _apply_prefix_caching, repeated worker restarts, and unusual multi-prompt completion requests from a single source.
What systems are affected by CVE-2026-94623?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference clusters, prefill/decode disaggregated serving, OpenAI-compatible API gateways, RAG pipelines, agent frameworks.
What is the CVSS score for CVE-2026-94623?
CVE-2026-94623 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
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0040AI Model Inference API AccessAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM through 0.29.0 contains a denial of service vulnerability in the NIXL connector's prefix caching implementation that fails to properly validate block counts across multi-prompt completion requests in prefill/decode disaggregated deployments. Attackers can trigger an assertion failure in NixlBaseConnectorWorker._apply_prefix_caching by submitting completion requests with multiple prompts of varying lengths, causing the decode worker to terminate and become unavailable until restarted.
Exploitation Scenario
An attacker finds an exposed or weakly authenticated vLLM OpenAI-compatible endpoint backed by a disaggregated prefill/decode deployment using NIXL. They send a /v1/completions request with a prompt array holding several prompts of different lengths. Block counts are not validated across the prompts, the assertion in _apply_prefix_caching fails, and the decode worker exits. By repeating the request each time the worker restarts, the attacker keeps the inference service degraded or offline, disrupting dependent AI applications and agent workflows.
Weaknesses (CWE)
CWE-617 — Reachable Assertion: The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
- [Implementation] If the assertion statement is required (e.g., for security or reliability), change the invoking code to avoid the conditions that trigger the assertion.
- [Implementation] Consider changing the assertion to some other less "fatal" error. This might not be easy to implement, since other code may be needed to handle the error.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
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