vLLM: vLLM has Remote DoS via Invalid Recovered Token Reinjection
vLLM
More for vLLM RSS feed for vLLM
- Severity
- High, CVSS 7.5
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Record
- CVE-2026-54234
- Affects
- vLLM
- Known exploited
- Not listed in the CISA Known Exploited Vulnerabilities catalog
- Published
- Record first published by the source
- July 6, 2026
- Source last modified
- October 25, 2026
Description
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.
Description quoted from the NVD record.
Who is affected
vLLM is software that runs AI language models so that other programs and people can send them requests and get answers. This flaw affects versions before 0.24.0, in setups that use a speed-up feature where the system guesses ahead at the next words (called speculative decoding). Anyone who can send text requests to the service over the network can send a series of requests that crashes the shared engine. This cancels other users' requests in progress and makes the service unavailable to everyone until it is restarted. This flaw is rated High.
What to do
- The person who installed or runs vLLM for your organization should check which version is in use. Any version before
0.24.0has this flaw. - Update vLLM to version
0.24.0or later, which fixes this flaw. - If an IT provider or vendor runs vLLM for your organization, send them this advisory and ask when the update will be done.
- Until the update is done, if the service suddenly stops answering everyone at once, restart it to bring it back. This flaw keeps the service down until it is restarted.
Analysis written from the source record as of October 25, 2026 and reviewed before publishing.