AI Threat Alert
CVE-2026-54234: vLLM: crafted spec-decoding request crashes GPU worker (DoS)
GHSA-8wr5-jm2h-8r4f HIGH PoC AVAILABLE CISA: TRACK*A remote, unauthenticated client can send a specially-crafted multi-request speculative decoding sequence to vLLM's public gRPC Generate/Abort endpoints that forces the rejection sampler to emit an out-of-vocabulary token, which crashes the shared GPU engine worker via a device-side assertion. Because vLLM serves many concurrent requests on a single shared worker, one malicious client can knock out inference for every other tenant on that deployment until the process is restarted — a classic shared-infrastructure blast-radius problem for any multi-tenant or public-facing LLM serving stack. With 129 downstream dependents, a package risk score of 61/100, and a public PoC already available (no EPSS data yet, not in CISA KEV), this is a low-complexity, network-reachable, no-auth-required denial-of-service against a widely deployed inference engine. Patch to vLLM 0.24.0 immediately on any internet- or tenant-facing deployment; where immediate patching isn't possible, disable or gate speculative decoding and restrict gRPC Generate/Abort access to trusted callers only, and monitor worker logs for repeated CUDA device-side assertion crashes as a detection signal.
What is the risk?
High-severity availability-only issue (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/A:H). Exploitability is high: the trigger is reachable through standard public gRPC endpoints (Generate, Abort), requires no authentication or privileges, and a public PoC exists, meaning attackers do not need to reverse-engineer the flaw. There is no confidentiality or integrity impact — this is a pure denial-of-service against the inference worker — but the shared-worker architecture of vLLM means a single malicious or even accidentally malformed request sequence can take down service for all co-tenants. Not in CISA KEV and no EPSS score is available, so there is no confirmed evidence of active mass exploitation yet, but the combination of network exposure, low complexity, and public PoC makes real-world exploitation attempts likely, especially against multi-tenant inference-as-a-service deployments.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | >= 0.17.1, < 0.24.0 | 0.24.0 |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade to vLLM 0.24.0 or later immediately — this is the definitive fix. 2) If immediate patching isn't feasible, disable speculative decoding (
--speculative-model/related flags) as a stopgap, since the flaw is specific to the speculative decoding rejection sampler path. 3) Restrict network access to the gRPC Generate/Abort endpoints to trusted internal callers via network policy/mTLS/API gateway auth rather than exposing them directly to the internet. 4) Add process-level auto-restart/supervision (e.g., systemd, Kubernetes liveness probes) so a worker crash triggers fast recovery and doesn't require manual intervention. 5) For detection, monitor engine logs for CUDA device-side assertion errors and correlate with abnormal spikes in Abort-then-Generate request sequences from a single client/IP. 6) In multi-tenant deployments, consider per-tenant worker isolation to contain blast radius from any future similar bug.
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-54234?
A remote, unauthenticated client can send a specially-crafted multi-request speculative decoding sequence to vLLM's public gRPC Generate/Abort endpoints that forces the rejection sampler to emit an out-of-vocabulary token, which crashes the shared GPU engine worker via a device-side assertion. Because vLLM serves many concurrent requests on a single shared worker, one malicious client can knock out inference for every other tenant on that deployment until the process is restarted — a classic shared-infrastructure blast-radius problem for any multi-tenant or public-facing LLM serving stack. With 129 downstream dependents, a package risk score of 61/100, and a public PoC already available (no EPSS data yet, not in CISA KEV), this is a low-complexity, network-reachable, no-auth-required denial-of-service against a widely deployed inference engine. Patch to vLLM 0.24.0 immediately on any internet- or tenant-facing deployment; where immediate patching isn't possible, disable or gate speculative decoding and restrict gRPC Generate/Abort access to trusted callers only, and monitor worker logs for repeated CUDA device-side assertion crashes as a detection signal.
Is CVE-2026-54234 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-54234, increasing the risk of exploitation.
How to fix CVE-2026-54234?
1) Upgrade to vLLM 0.24.0 or later immediately — this is the definitive fix. 2) If immediate patching isn't feasible, disable speculative decoding (`--speculative-model`/related flags) as a stopgap, since the flaw is specific to the speculative decoding rejection sampler path. 3) Restrict network access to the gRPC Generate/Abort endpoints to trusted internal callers via network policy/mTLS/API gateway auth rather than exposing them directly to the internet. 4) Add process-level auto-restart/supervision (e.g., systemd, Kubernetes liveness probes) so a worker crash triggers fast recovery and doesn't require manual intervention. 5) For detection, monitor engine logs for CUDA device-side assertion errors and correlate with abnormal spikes in Abort-then-Generate request sequences from a single client/IP. 6) In multi-tenant deployments, consider per-tenant worker isolation to contain blast radius from any future similar bug.
What systems are affected by CVE-2026-54234?
This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks, RAG pipelines.
What is the CVSS score for CVE-2026-54234?
CVE-2026-54234 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.36%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029 Denial of AI Service AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, 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, which is then converted to negative one when the engine selects the next live token for a request and is written back into the drafter's input ids; that out-of-vocabulary value is later consumed by the model's embedding and attention path and crashes the engine worker with a GPU device-side assertion. The same triggering request sequence is reachable through the public gRPC Generate and Abort endpoints, so a remote client that can send generation requests can crash the shared engine worker, aborting concurrent requests and causing a service-wide denial of service for other clients of the deployment until the worker is restarted. This issue is fixed in version 0.24.0.
Exploitation Scenario
An attacker with no credentials sends a sequence of Generate and Abort gRPC calls to a public-facing vLLM endpoint, deliberately shaping the multi-request speculative decoding workload so the rejection sampler produces a recovered token at the exact model vocabulary size boundary. When the engine converts this boundary value to -1 and writes it back into the drafter's input IDs, the out-of-vocabulary index is later consumed by the model's embedding/attention layers, triggering a GPU device-side assertion that crashes the shared engine worker process. Every other user or tenant with in-flight requests on that worker has their requests aborted simultaneously, and the service remains unavailable until an operator or orchestrator restarts the worker — enabling a low-cost, repeatable denial-of-service against the entire inference deployment.
Weaknesses (CWE)
CWE-1284 Improper Validation of Specified Quantity in Input
Primary
CWE-20 Improper Input Validation
Primary
CWE-20 Improper Input Validation
Primary
CWE-1284 Improper Validation of Specified Quantity in Input CWE-20 Improper Input Validation CWE-1284 — Improper Validation of Specified Quantity in Input: The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H References
Timeline
Related Vulnerabilities
CVE-2024-9053 9.8 vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm CVE-2026-25960 9.8 vllm: SSRF allows internal network access
Same package: vllm CVE-2025-47277 9.8 vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllm CVE-2024-11041 9.8 vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllm CVE-2025-32444 9.8 vLLM: RCE via pickle deserialization on ZeroMQ
Same package: vllm