CVE-2025-62426: vLLM Denial of Service (DoS) Vulnerability

CVE-2025-62426 Overview

CVE-2025-62426 is a denial-of-service vulnerability in vLLM, an inference and serving engine for large language models (LLMs). The flaw affects the /v1/chat/completions and /tokenize endpoints in versions 0.5.5 through 0.11.0. These endpoints accept a chat_template_kwargs request parameter that is passed into template processing before proper validation occurs. Authenticated attackers can supply crafted chat_template_kwargs values that cause the API server to block for extended periods, delaying all other requests. The issue is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling]. Maintainers released a fix in version 0.11.1.

Critical Impact
A remote authenticated attacker can stall the vLLM API server for prolonged periods, denying service to all concurrent inference requests.

Affected Products

vLLM versions 0.5.5 through 0.11.0
vLLM 0.11.1-rc0 (release candidate)
vLLM 0.11.1-rc1 (release candidate)

Discovery Timeline

2025-11-21 - CVE-2025-62426 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-62426

Vulnerability Analysis

vLLM exposes OpenAI-compatible HTTP endpoints for chat completion and tokenization. Both endpoints accept a chat_template_kwargs dictionary that is forwarded into Jinja-based chat template rendering. Prior to the patch, the server did not restrict which keys clients could pass. Attackers could inject template-controlling arguments that trigger expensive rendering paths or force the server to serialize large outputs during a single request. Because vLLM processes template application on the API server thread, this stall blocks other queued requests, producing a service-wide slowdown. The vulnerability requires only low-privilege API access with no user interaction.

Root Cause

The root cause is missing input validation in the chat template kwargs handling path in vllm/entrypoints/chat_utils.py and vllm/entrypoints/openai/serving_engine.py. The pre-patch code excluded only the chat_template key from client-controlled kwargs. It did not exclude control parameters such as tokenize, which alter template execution behavior and can be abused to inflate processing cost.

Attack Vector

An authenticated client sends a POST request to /v1/chat/completions or /tokenize with a chat_template_kwargs object containing crafted keys. The server accepts the kwargs, invokes apply_chat_template, and enters a long-running template evaluation. Concurrent requests to the same worker are delayed until the abusive request completes.

python

     tokenizer: PreTrainedTokenizer | PreTrainedTokenizerFast,
     chat_template: str,
     chat_template_kwargs: dict[str, Any],
+    raise_on_unexpected: bool = True,
 ) -> dict[str, Any]:
+    # We exclude chat_template from kwargs here, because
+    # chat template has been already resolved at this stage
+    unexpected_vars = {"chat_template", "tokenize"}
+    if raise_on_unexpected and (
+        unexpected_in_kwargs := unexpected_vars & chat_template_kwargs.keys()
+    ):
+        raise ValueError(
+            "Found unexpected chat template kwargs from request: "
+            f"{unexpected_in_kwargs}"
+        )
+
     fn_kw = {
         k
         for k in chat_template_kwargs
         if supports_kw(tokenizer.apply_chat_template, k, allow_var_kwargs=False)
     }
-
     template_vars = _cached_resolve_chat_template_kwargs(chat_template)
-
-    # We exclude chat_template from kwargs here, because
-    # chat template has been already resolved at this stage
-    unexpected_vars = {"chat_template"}
     accept_vars = (fn_kw | template_vars) - unexpected_vars
     return {k: v for k, v in chat_template_kwargs.items() if k in accept_vars}

Source: GitHub Commit 3ada34f9. The patch adds tokenize to the unexpected-vars set and raises ValueError when clients include disallowed keys.

Detection Methods for CVE-2025-62426

Indicators of Compromise

Repeated POST requests to /v1/chat/completions or /tokenize containing a chat_template_kwargs field with unusual keys such as tokenize or template-control variables.
API server request latency spikes correlated with a small number of client sessions.
Backlog of pending requests on a vLLM worker while CPU usage remains pinned on template rendering.

Detection Strategies

Inspect application logs and reverse-proxy logs for chat_template_kwargs payloads sent to the affected endpoints and alert on anomalous key names.
Track per-request duration for /v1/chat/completions and /tokenize and alert when tail latency exceeds baseline thresholds.
Rate-limit and record clients whose requests repeatedly exceed expected processing time.

Monitoring Recommendations

Enable structured request logging on the vLLM API gateway to capture request bodies for post-incident analysis.
Export vLLM Prometheus metrics for queue depth, request latency, and worker utilization into your SIEM.
Correlate authenticated API tokens with request-latency outliers to identify abusive credentials.

How to Mitigate CVE-2025-62426

Immediate Actions Required

Upgrade vLLM to version 0.11.1 or later on every inference host running the OpenAI-compatible server.
Restrict network exposure of /v1/chat/completions and /tokenize to trusted clients using authentication and network segmentation.
Enforce per-client request timeouts and concurrency limits at the reverse proxy or API gateway.

Patch Information

The fix is committed in vLLM as commit 3ada34f9 and delivered via pull request #27205. See the GHSA-69j4-grxj-j64p advisory for maintainer guidance. The patch rejects unexpected chat_template_kwargs keys including tokenize and chat_template.

Workarounds

Place a validating reverse proxy in front of vLLM that strips or rejects chat_template_kwargs fields on inbound requests.
Configure request-size and timeout limits at the ingress layer to bound the impact of long-running template evaluations.
Disable anonymous or shared API keys and require per-user authentication to enable revocation of abusive clients.

bash

# Upgrade vLLM to the patched release
pip install --upgrade "vllm>=0.11.1"

# Verify the installed version
python -c "import vllm; print(vllm.__version__)"