GHSA-8wr5-jm2h-8r4f

Summary

A frontend-legal multi-request speculative workload can make vLLM produce an out-of-vocabulary recovered token equal to vocab_size, convert that value to -1 when choosing the next live token for a request, and then feed that -1 back into the next drafter input ids. On Qwen3 GPTQ this reaches the worker-side drafting / attention path and crashes the engine with a GPU device-side assert.

The same issue is reachable through the public gRPC request surface by sending a specific overlapping Generate / Abort sequence.

Impact

• A remote client that can send public gRPC generation requests can crash the shared vLLM engine worker
• The triggering request sequence aborts concurrent requests and prevents later requests from completing until the worker is restarted
• In shared deployments, this is a service-wide denial of service for other clients, not just a failure isolated to the attacking requests
• The failure is reproducible, so repeated request sequences can sustain the outage

Affected version

• Confirmed on vLLM 0.17.1
• Earlier and later versions have not been checked yet in this report

Repro model

• Official Hugging Face repo:
  • Qwen/Qwen3-0.6B-GPTQ-Int8
• Anyone wants to reproduce the bug with my PoC scripts should download Qwen3-0.6B-GPTQ-Int8 first

Trigger chain

1. A legal multi-request speculative workload keeps structured-output state, speculative decoding, overlap, and request cancellation active in the same live engine.
2. During rejection sampling, vLLM produces a recovered token equal to the model vocab_size boundary value.
3. That recovered token appears in position 0 of the sampled speculative row for a live request. The same row also contains trailing padding entries equal to -1, but those padding entries are not the key fault by themselves.
4. The next-token preparation step treats the position-0 recovered token as the...