CVE-2026-94623: vLLM NIXL Connector DOS Vulnerability

CVE-2026-94623 Overview

CVE-2026-94623 is a denial of service vulnerability in vLLM through version 0.29.0. The flaw resides in the NIXL connector's prefix caching implementation, which fails to 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 containing multiple prompts of varying lengths. The failure terminates the decode worker, making the vLLM inference service unavailable until an operator restarts it. The vulnerability is classified as a reachable assertion condition under [CWE-617].

Critical Impact
Unauthenticated network attackers can crash vLLM decode workers with a single crafted multi-prompt completion request, causing service outage for AI inference workloads.

Affected Products

vLLM inference server versions up to and including 0.29.0
Deployments using the NIXL KV transfer connector
Prefill/decode disaggregated vLLM topologies

Discovery Timeline

2026-09-21 - CVE-2026-94623 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-94623

Vulnerability Analysis

vLLM is a high-throughput inference and serving engine for large language models. In disaggregated deployments, prefill workers compute the initial key-value (KV) cache and transfer it to decode workers via the NIXL connector. The prefix caching optimization reuses KV blocks across requests that share input tokens.

The vulnerability stems from an unchecked precondition in NixlBaseConnectorWorker._apply_prefix_caching. When a completion request contains multiple prompts of differing lengths, the connector computes block counts that violate an internal invariant enforced by a Python assert statement. The assertion fires, raising AssertionError inside the worker's request-handling path. Because the failure is not caught and recovered, the decode worker process terminates.

The result is a durable denial of service: the affected worker remains down until an operator restarts it. In production inference clusters, this converts a single malformed request into an outage of the decode tier.

Root Cause

The root cause is missing input validation for multi-prompt batch requests. The NIXL worker assumes uniform prompt structure when computing prefix cache block counts and enforces that assumption with a hard assertion rather than a recoverable error path. Any client-supplied combination of prompt lengths that violates the invariant becomes an availability bug. Reference the vulnerable region at vLLM base_worker.py L2642-L2646.

Attack Vector

Exploitation requires network access to the vLLM HTTP inference endpoint and no authentication when the server is deployed with default open access. An attacker sends a standard completion request whose prompt field contains an array of strings with varying token lengths. The request reaches the NIXL prefix caching path on the decode worker, the assertion fails, and the worker exits. Repeat requests against restarted workers sustain the outage. Technical details are documented in the VulnCheck advisory for the vLLM NIXL multi-prompt assertion failure.

No verified proof-of-concept code is published. See the referenced advisory and source for technical details.

Detection Methods for CVE-2026-94623

Indicators of Compromise

Unhandled AssertionError stack traces in vLLM worker logs referencing NixlBaseConnectorWorker._apply_prefix_caching
Unexpected decode worker process exits followed by orchestrator restart events (Kubernetes CrashLoopBackOff, systemd restart entries)
HTTP /v1/completions requests containing a prompt array with multiple entries of significantly different lengths originating from untrusted sources

Detection Strategies

Parse vLLM stdout/stderr for the assertion signature in the NIXL worker module and alert on any occurrence
Correlate inference API 5xx responses with concurrent worker restart metrics to identify DoS attempts
Baseline typical prompt array sizes for legitimate clients and flag outliers containing mixed-length multi-prompt batches

Monitoring Recommendations

Ship vLLM container logs to a centralized logging pipeline and create detections for AssertionError in base_worker.py
Monitor decode worker uptime, restart counts, and request queue depth as availability signals
Track per-source-IP request rates to the completions endpoint to identify repeated crash-trigger attempts

How to Mitigate CVE-2026-94623

Immediate Actions Required

Upgrade vLLM to a release that incorporates the fix from vLLM Pull Request #51505 once available beyond 0.29.0
Restrict network exposure of vLLM inference endpoints to trusted clients using firewall rules, service mesh policies, or an authenticating reverse proxy
Enable request validation at the ingress layer to reject completion requests with multi-prompt arrays until patched

Patch Information

The upstream fix is tracked in vLLM Pull Request #51505 in the vLLM project repository. Operators running 0.29.0 or earlier with the NIXL connector should update to a fixed release and redeploy prefill/decode worker pools.

Workarounds

Disable the NIXL KV transfer connector where prefill/decode disaggregation is not required
Deploy an API gateway rule that rejects /v1/completions payloads whose prompt field is an array of length greater than one until patching is complete
Place vLLM behind an authenticating proxy to prevent unauthenticated attackers from reaching the vulnerable code path

bash

# Example ingress filter: reject multi-prompt completion requests
# (nginx snippet, adjust for your gateway)
location /v1/completions {
    if ($request_method = POST) {
        access_by_lua_block {
            local cjson = require "cjson.safe"
            ngx.req.read_body()
            local body = ngx.req.get_body_data()
            local data = body and cjson.decode(body)
            if data and type(data.prompt) == "table" and #data.prompt > 1 then
                ngx.exit(400)
            end
        }
    }
    proxy_pass http://vllm_upstream;
}