vLLM Unbounded Completion Multiplicity DoS

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.

Netzilo detection

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/