vLLM Derender Endpoint Unbounded Token Decode
vLLM exposes endpoints that turn token IDs back into text (derender). Because these endpoints don't check how many tokens or choices are in a request, an authenticated caller can send absurdly large or fabricated data to force expensive decoding work, slowing or crashing the service for everyone else using it.
How the attack works
An attacker sends a POST to /v1/completions/derender or /v1/chat/completions/derender with a payload containing a token_ids list. Instead of a normal short response, the attacker supplies either one huge token array (tens of thousands of characters, thousands of token IDs), token IDs with 8+ digits that no real tokenizer vocabulary would produce, or a request with 100+ separate 'choices' to decode. The server calls its decode function on all of this without checking against configured max_tokens, context length, or choice-count limits. This consumes CPU and memory disproportionate to a normal request, degrading the shared inference frontend for other users.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f6b1c94-2d5a-4e08-9b71-0a4c8d5e2716
- Severity
- Medium
Why it matters
A single authenticated request can degrade or stall the inference frontend for all clients sharing that process, causing a denial-of-service condition without needing to compromise credentials or bypass authentication.
What you can do
- →Enforce server-side limits on token_ids array length, choice count, and total decode payload size before calling tokenizer.decode().
- →Validate that submitted token IDs fall within the actual tokenizer vocabulary range and reject out-of-range values.
- →Rate-limit or isolate derender endpoint calls per client so one abusive request cannot exhaust shared resources.
- →Review load-testing and CI fuzzing traffic against this endpoint to distinguish legitimate large payloads from genuine abuse before treating alerts as incidents.
Known benign look-alikes
- Offline or batch rendering pipeline legitimately derendering a single very long generation (more than roughly 4,000 token IDs in one choice) produced with a high max_tokens setting.
- Platform-team load or latency benchmarking of the render frontend against a staging vLLM deployment, which deliberately submits oversized token_ids arrays.
- CI fuzzing or security regression suites that replay the oversized-derender payload to verify a bounds check is in place.
- A client with corrupted or truncated local state emitting malformed token ID values (matches the out-of-range indicator without malicious intent).
- A legitimate high-n serving configuration that returns more than 100 choices per request, if such a deployment exists locally.