Executive brief
vLLM is a large language model inference engine that includes OpenAI-compatible API endpoints for text generation. The `/v1/completions/derender` and `/v1/chat/completions/derender` endpoints accept caller-supplied pre-generated token sequences without enforcing the same output size limits that apply to normal generation. An authenticated attacker can send oversized token lists, forcing the server to decode and process them without bounds, consuming CPU and memory and degrading availability for legitimate clients.
Technical details
The derender endpoints (`/v1/completions/derender` and `/v1/chat/completions/derender`) in `vllm/entrypoints/serve/render/api_router.py` accept `GenerateResponse` objects containing caller-supplied `choices[*].token_ids` lists from HTTP clients. The request schemas (`GenerateResponse`, `GenerateResponseChoice`, `DerenderCompletionRequest` in `vllm/entrypoints/serve/disagg/protocol.py`) have no maximum bounds on token list length, choice count, or response size. The `OnlineDerenderer.derender_completion()` and `derender_chat()` methods in `vllm/renderers/online_derenderer.py` iterate over each supplied token list and call `tokenizer.decode()` directly without validating that the aggregate token/choice/response sizes respect the model's `max_model_len`, `max_tokens`, or `max_num_seqs` limits that are enforced during normal generation. An authenticated API client (with API-key if configured) can craft a derender request with extremely large or numerous token lists, forcing tokenizer decoding, text assembly, and response construction to consume unbounded CPU and memory before any bounds-checking occurs. The attack requires API authentication (reducing severity slightly from unauthenticated), but affects the frontend rendering process or shared server infrastructure.
Affected products
- vllm-project vLLM < 0.26.0
Timeline
- 2026-07-27: disclosed
- 2026-09-04: advisory: GitHub Security Advisory GHSA-8737-qx52-hjff published
- 2026-09-04: patched: Fixed in vLLM v0.26.0