# vLLM Unbounded Completion Multiplicity DoS

- **Severity:** High
- **Signature ID:** `b7c4e1a9-3f52-4d8e-9a61-0c7d5f2ab834`

## Summary

Attackers can crash an AI inference server by asking it to generate an absurdly large number of completions in a single request. vLLM and similar OpenAI-compatible servers don't check whether this number is reasonable before trying to fulfill it, so the server exhausts memory and freezes.

## How the attack works

The attacker sends a normal-looking completion request to a chat or text completion endpoint, but sets the 'n', 'best_of', or 'num_return_sequences' parameter to an extremely high value. vLLM's request handling clones the entire request object that many times on the heap before its scheduler gets a chance to reject or queue it. This drives the server out of memory and blocks its event loop, making it unresponsive to other requests. The detection watches for repeated oversized-multiplicity requests hitting the same endpoint within a short window, distinguishing a sustained attack from a one-off large batch job.

## Why it matters

A single crafted request, or a small burst of them, can take down a self-hosted inference server, denying service to all legitimate users of that endpoint until it is restarted.

## What you can do

- Enforce a hard upper bound on n, best_of, and num_return_sequences at the API gateway or application layer, independent of the inference server's own validation.
- Rate-limit and monitor completion requests per client, especially spikes in requested sample count.
- If running benchmarking or pass@k evaluation jobs that legitimately use high n values, run them from known, allow-listed agents or schedule them separately so they don't blend with production traffic.
- Patch or configure the inference server to reject requests with unreasonable multiplicity parameters before allocation happens.

## Known benign look-alikes

- Capacity or throughput benchmarking against a lab inference endpoint (vLLM's own benchmark_serving harness and similar tools deliberately push large n/best_of). Such runs are repeated and will be reported - suppress by scheduling them or by excluding the benchmark agent at policy level, not by widening this rule.
- Legitimate pass@k / self-consistency evaluation jobs that request dozens of samples per prompt. The script requires n >= 24 and, below n = 256, at least one corroborating graph or repetition signal before it reports.
- A prompt or attached document that itself contains a pretty-printed JSON snippet with a large "n" field. Mitigated by requiring the key to be preceded by '{' or ',' (string-escaped JSON inside a message body is preceded by a backslash) and by requiring the request path to be a completions endpoint.
- A shared egress proxy or gateway that funnels many clients' completions to one endpoint, inflating the HTTP_REQUEST edge count. The flood signal is only ever a corroborating stage, never the sole trigger.

## References

- https://github.com/vllm-project/vllm/security/advisories
- https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/
- https://attack.mitre.org/techniques/T1499/004/

---
Source: https://www.netzilo.com/threats/vllm-unbounded-completion-multiplicity-dos