# vLLM Derender Endpoint Unbounded Token Decode

- **Severity:** Medium
- **Signature ID:** `3f6b1c94-2d5a-4e08-9b71-0a4c8d5e2716`
- **MITRE ATLAS:** AML.T0029 (Denial of AI Service)
- **OWASP:** LLM10 (Unbounded Consumption)

## Summary

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.

## 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.

## References

- https://genai.owasp.org/llmrisk/llm102025-unbounded-consumption/
- https://atlas.mitre.org/techniques/AML.T0029
- https://attack.mitre.org/techniques/T1499/
- https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html

---
Source: https://www.netzilo.com/threats/vllm-derender-unbounded-token-decode