CVE-2026-54234: 
NixOS vulnerability analysis and mitigation

CVE-2026-54234 is a remote Denial of Service vulnerability in vLLM (a high-throughput LLM inference engine) caused by invalid recovered token reinjection during speculative decoding. A frontend-legal multi-request speculative decoding workload can cause the rejection sampler to produce a recovered token equal to the model vocabulary size boundary value (vocab_size), which is then converted to -1 and fed back into the drafter's input IDs, ultimately crashing the GPU engine worker. All vLLM versions from 0.17.1 up to (but not including) 0.24.0 are affected. The vulnerability was published on July 6, 2026, with a fix merged on June 10, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Github Advisory).

The root cause is a speculative-decoding state-handling bug classified as CWE-20 (Improper Input Validation), CWE-1284 (Improper Validation of Specified Quantity in Input), and CWE-125 (Out-of-bounds Read). When vocab_size is not a multiple of the Triton kernel's BLOCK_SIZE (8192), the last tile in sample_recovered_tokens_kernel extends beyond the vocabulary boundary; if all valid entries in that tail tile have zero target probability, the out-of-range masked positions (score 0) can win the tl.max tie-break, producing recovered_id >= vocab_size. This out-of-vocabulary value is then selected as the live next token for a request, converted to -1, written back into the drafter's input IDs via set_inputs_first_pass, and subsequently consumed by the model's embedding and attention path (embed_tokens), triggering a CUDA error: device-side assert triggered that kills the engine worker. The triggering request sequence uses only standard SamplingParams features (structured outputs, stop, bad_words, min_tokens, streaming overlap) and is reachable through the public gRPC Generate and Abort endpoints without any malformed token input (GitHub Advisory, Fix PR).

Successful exploitation causes a complete, service-wide denial of service: the shared vLLM engine worker crashes, aborting all concurrent requests from all clients until the worker is manually restarted. Because the failure is reproducible and requires no authentication or special privileges, an attacker can sustain the outage by repeatedly sending the triggering request sequence. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue affecting all users of a shared vLLM deployment (GitHub Advisory, Red Hat Bugzilla).

Proof-of-concept exploit code is publicly available in the form of two standalone Python scripts (repro_g4_recovered_minus1_local.py and repro_g4_recovered_minus1_grpc.py) included in the security advisory, confirmed to reliably reproduce the crash on real vLLM deployments (GitHub Advisory). The NVD SSVC assessment classifies the vulnerability as automatable with PoC-level exploitation. No in-the-wild exploitation has been reported as of the time of publication, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.34%, placing it in the 27th percentile for exploitation likelihood (Github Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible vLLM deployments running versions >= 0.17.1 and < 0.24.0 with speculative decoding enabled (e.g., using EAGLE or similar drafter) and a model with a non-BLOCK_SIZE-aligned vocabulary (e.g., Qwen3-0.6B-GPTQ-Int8 with vocab_size=151936).
2. Prepare the gRPC reproducer: Obtain or adapt the public PoC script repro_g4_recovered_minus1_grpc.py. Configure it with the target vLLM gRPC server address and the appropriate model path via the VLLM_POC_G4_MODEL environment variable.
3. Send overlapping Generate/Abort sequence: Execute the script, which sends a fixed overlapping sequence of public Generate and Abort gRPC RPCs designed to keep structured-output state, speculative decoding, overlap, and request cancellation simultaneously active in the live engine.
4. Trigger out-of-vocabulary token: The crafted workload causes the rejection sampler's sample_recovered_tokens_kernel to produce recovered_token_ids[0] = vocab_size (e.g., 151936), which is then converted to -1 and written into the drafter's live input IDs.
5. Crash the engine worker: The invalid -1 token is consumed by the model's embedding path (embed_tokens), triggering CUDA error: device-side assert triggered and a fatal EngineDeadError, crashing the shared worker and aborting all concurrent requests.
6. Confirm and sustain DoS: Send a follow-up Generate probe request to confirm the worker is dead (it will fail with EngineCore encountered an issue). Repeat the sequence to sustain the outage until the worker is restarted (GitHub Advisory).

• Logs (vLLM server stderr/stdout):
  • torch.AcceleratorError: CUDA error: device-side assert triggered appearing in server.stderr.log
  • vllm.v1.engine.exceptions.EngineDeadError: EngineCore encountered an issue. See stack trace (above) for the root cause.
  • INTERNAL: EngineCore encountered an issue. returned to gRPC clients
  • Error in Generate for request <id>: EngineDeadError for requests submitted after the crash
• Recovered-chain trace artifacts (if tracing is enabled):
  • sample_recovered_tokens_return: recovered_token_ids = [151936, ...] (or any value equal to vocab_size)
  • prepare_next_token_ids_padded: next_token_ids = [-1, ...]
  • set_inputs_first_pass: input_ids_after = [-1, 0, 0, 0, ...]
  • embed_input_ids_out_of_range: input_ids = [-1, 0, 0, 0, ...]
• Network:
  • Rapid succession of gRPC Generate and Abort RPC calls from a single client to the vLLM gRPC endpoint, followed by a sudden drop in successful responses from all clients
• Process:
  • Unexpected termination/restart of the vLLM engine worker process
  • All concurrent inference requests failing simultaneously (GitHub Advisory)

The primary remediation is to upgrade vLLM to version 0.24.0 or later, which contains the fix merged in PR #44744 (commit 8a5cf1c). The fix masks out-of-vocabulary entries to -inf in sample_recovered_tokens_kernel so they can never win the tiled argmax, and adds a belt-and-suspenders clamp on recovered_id before storing. If immediate patching is not possible, implement network-level access controls to restrict which clients can send requests to the vLLM gRPC endpoints, or deploy redundant vLLM workers with automatic failover to minimize service disruption from worker crashes (Fix PR, GitHub Advisory).

The vulnerability was reported by security researcher NeilAlfred and coordinated by jperezdealgaba, who also authored the fix. The fix was reviewed and approved by vLLM maintainer MatthewBonanni and merged on June 10, 2026. Red Hat tracked the issue via Bugzilla (Bug 2497515) with high priority and severity. The advisory received attention on Mastodon shortly after disclosure. Multiple downstream forks and distributions (including NixOS and several community vLLM forks) promptly cherry-picked the security fix (Red Hat Bugzilla, Fix PR).