On April 2025, security researchers discovered CVE-2025-46560 — a critical performance vulnerability in the vLLM serving engine for large language models (LLMs). This bug allowed attackers to cause severe resource exhaustion just by sending cleverly crafted input.

vLLM is an open-source project designed for efficient and high-throughput inference with LLMs, such as those powering chatbots and enterprise AI applications. It’s used widely — even small issues in its code can ripple into big problems for AI deployments.

Here, we’ll break down what happened, show the code, walk through an example exploit, and help you patch or protect your systems if you use vLLM.

What’s the Issue?

Affected versions:

vLLM .8. through any version before .8.5

Fixed in:
- vLLM .8.5 (Changelog)

The vulnerable code is in the multimodal tokenizer’s input preprocessing logic. Specifically, it handles special placeholder tokens, such as <|image_|> or <|audio_|>. The code replaces these placeholders dynamically with a list of repeated tokens whose length is precomputed. However, the logic used for appending these tokens is inefficient: it repeatedly builds larger and larger lists using concatenation, falling into a quadratic time complexity (O(n²)) pattern.

Why is This Dangerous?

If an attacker sends a long input with many such placeholders (or with huge target expansion sizes), vLLM will spend enormous amounts of CPU time and memory processing it. Servers can be slowed to a crawl or even crash — all with no actual sophisticated hacking, just input.

The Vulnerable Code

Let’s look at a simplified version of the problematic code.

Suppose in the multimodal tokenizer the logic looked something like this

# Vulnerable code snippet

tokens = []
for chunk in input_chunks:
    if is_placeholder(chunk):
        # e.g., replace <|image_|> with N repeated tokens
        tokens = tokens + [PLACEHOLDER_TOKEN] * get_length(chunk)
    else:
        tokens.append(tokenize(chunk))

Here, tokens + [...] creates a brand new list, every time, containing all previous elements plus new ones. So, if we call this k times, the work done grows like 1 + 2 + 3 + ... k = O(k^2). Large or numerous placeholders mean huge, unnecessary CPU/memory usage.

The Correct Way?

It should use tokens.extend([...]) or similar methods that avoid building new lists every iteration.

Suppose an attacker sends input like this

# Pseudo user input string:
"<|image_|><|image_|><|image_|>...<|image_|>"  # Repeated hundreds or thousands of times

Each <|image_|> could be set to expand into (say) 4096 tokens.

...

The total “add up so far” pattern means that for n placeholders, the time and space will scale with O(n²) — quickly overwhelming the server.

Proof-of-Concept (PoC)

# PoC: Simulate the vulnerable code’s behavior
PLACEHOLDER_TOKEN = 42
FAKE_CHUNK_COUNT = 200  # Large count triggers resource exhaustion

tokens = []
for _ in range(FAKE_CHUNK_COUNT):
    # Triggers inefficient concatenation each time
    tokens = tokens + [PLACEHOLDER_TOKEN] * 4096  # Simulate long expansion

print("Generated", len(tokens), "tokens.")

Run this code: your CPU and RAM usage will spike dramatically!

Abusable as a Denial-of-Service (DoS) primitive

If your application relies on user-supplied data, AI assistants, or APIs, your endpoint is at risk.

The fix landed in vLLM .8.5

Summary of fix:

Fixed code pattern

# Fixed code
tokens = []
for chunk in input_chunks:
    if is_placeholder(chunk):
        tokens.extend([PLACEHOLDER_TOKEN] * get_length(chunk))
    else:
        tokens.append(tokenize(chunk))

Or, the code now may build a list of all new tokens, then do a single list addition at the end.

Upgrade vLLM immediately to .8.5 or newer.

GitHub vLLM releases

References

- Official vLLM Security Advisory for CVE-2025-46560
- vLLM Release Notes v.8.5
- What is O(n²)?—Simple Explanation
- Denial of Service via Algorithmic Complexity

Conclusion

Performance bugs can be just as dangerous as classic security vulnerabilities. With CVE-2025-46560, a simple coding oversight created a major attack surface. All users of affected vLLM versions should update immediately.

If you deploy LLMs at scale, keep your inference stack up-to-date—small input-handling bugs can have real-world impact, and you don’t want your chatbot server to fall over because someone sent it a long string of <|image_|>.

Stay safe, patch promptly, and audit your code for O(n²) operations that can be triggered by outside input!


*(This post is original and exclusive; please link back if you share.)*

Timeline

Published on: 04/30/2025 01:15:52 UTC
Last modified on: 05/28/2025 19:15:56 UTC