CVE-2026-54234: Vllm Vllm Denial of Service Vulnerability

CVE-2026-54234 Overview

CVE-2026-54234 is a remote denial-of-service vulnerability in vLLM, a high-throughput inference and serving engine for large language models (LLMs). The flaw resides in the speculative decoding rejection sampler, which can produce a recovered token equal to the vocabulary size boundary. That value is later converted to negative one and consumed by the model embedding and attention path, triggering a GPU device-side assertion that crashes the engine worker. Any remote client with access to the public gRPC Generate and Abort endpoints can trigger the crash. All vLLM versions prior to 0.24.0 are affected.

Critical Impact
A single crafted request sequence crashes the shared engine worker, aborting all concurrent requests and causing service-wide denial of service until the worker restarts.

Affected Products

vLLM versions prior to 0.24.0
Deployments exposing the gRPC Generate endpoint
Deployments exposing the gRPC Abort endpoint

Discovery Timeline

2026-07-06 - CVE-2026-54234 published to NVD
2026-07-07 - Last updated in NVD database

Technical Details for CVE-2026-54234

Vulnerability Analysis

The vulnerability is classified under [CWE-20] Improper Input Validation and manifests within vLLM's speculative decoding pipeline. Speculative decoding uses a smaller drafter model to propose candidate tokens, which the target model then verifies via a rejection sampler. When multiple concurrent requests hit the sampler under specific conditions, the recovered token identifier can equal vocab_size, exceeding the valid token index range of [0, vocab_size - 1].

The engine subsequently converts this boundary value to -1 when selecting the next live token and writes it back into the drafter's input_ids buffer. The embedding lookup and attention kernels then dereference this out-of-vocabulary index on the GPU, tripping a device-side assertion in CUDA. The assertion crashes the engine worker process and terminates every in-flight request sharing that worker.

Root Cause

The root cause is missing bounds enforcement in the Triton rejection sampler kernel located at vllm/v1/sample/rejection_sampler.py. When all valid entries in the last vocabulary tile carry zero probability, the argmax reduction can select a padded slot outside the valid vocabulary range. The kernel does not mask out-of-vocabulary indices before the reduction, allowing recovered_id to reach vocab_size.

Attack Vector

Exploitation requires no authentication, no user interaction, and low attack complexity. A remote attacker sends a frontend-legal multi-request speculative decoding workload through the public gRPC Generate endpoint. The crafted sequence forces the rejection sampler into the boundary condition, producing the invalid token. Because vLLM engine workers are shared across tenants and requests, one attacker crashes concurrent generations for every client of the deployment.

python

             other=0.0,
         )
 
-        # Local tile reduction
+        # Local tile reduction.
+        # Mask out-of-vocabulary entries to -inf so they can never win
+        # the argmax — prevents producing recovered_id >= vocab_size
+        # when all valid entries in the last tile have zero probability.
         score = prob * inv_q
+        score = tl.where(vocab_mask, score, float("-inf"))
         local_max, local_id = tl.max(score, axis=0, return_indices=True)
 
         if local_max > max_val:
             max_val = local_max
             recovered_id = v + local_id
 
+    recovered_id = tl.minimum(recovered_id, vocab_size - 1)
     tl.store(output_token_ids_ptr + token_idx, recovered_id)

Source: vLLM commit 8a5cf1c. The patch masks out-of-vocabulary entries to -inf before the argmax and clamps recovered_id with tl.minimum(recovered_id, vocab_size - 1).

Detection Methods for CVE-2026-54234

Indicators of Compromise

GPU device-side assertion errors in engine worker logs, typically referencing CUDA error: device-side assert triggered during embedding or attention operations.
Abrupt engine worker process termination followed by aborted status returns for concurrent gRPC generation requests.
Repeated multi-request speculative decoding traffic from a single client immediately preceding worker crashes.

Detection Strategies

Monitor vLLM engine worker exit codes and correlate crashes with the gRPC request sequence delivered in the preceding window.
Alert on out-of-vocabulary index errors or -1 token identifiers appearing in drafter input buffers when debug logging is enabled.
Track anomalous concurrent request patterns targeting the Generate endpoint that consistently precede service disruption.

Monitoring Recommendations

Instrument the gRPC surface with per-client request-rate and error-rate metrics to identify abusive callers.
Collect GPU driver logs alongside vLLM worker logs so device-side assertions can be attributed to specific request IDs.
Track engine worker restart frequency as a service health signal and page on repeated restarts within a short interval.

How to Mitigate CVE-2026-54234

Immediate Actions Required

Upgrade vLLM to version 0.24.0 or later, which contains the fix from pull request #44744.
Restrict network exposure of the gRPC Generate and Abort endpoints to trusted clients until the upgrade is applied.
Deploy rate limiting and authentication in front of vLLM endpoints to reduce the blast radius of a crash-triggering client.

Patch Information

The vulnerability is fixed in vLLM 0.24.0. The remediation is documented in GitHub Security Advisory GHSA-8wr5-jm2h-8r4f and implemented in commit 8a5cf1c. The patch enforces a vocabulary mask in the Triton rejection sampler and clamps recovered_id to vocab_size - 1.

Workarounds

Disable speculative decoding in the vLLM configuration if the deployment cannot be upgraded immediately, since the vulnerable code path executes only when speculative decoding is enabled.
Place the gRPC service behind an authenticating reverse proxy that enforces per-tenant isolation and drops anomalous request bursts.
Automate engine worker restart on assertion failure with supervisor tooling to shorten downtime while patch rollout is in progress.

bash

# Configuration example: upgrade vLLM to the patched release
pip install --upgrade "vllm>=0.24.0"

# Verify installed version
python -c "import vllm; print(vllm.__version__)"