CVE-2025-48943: Vllm Vllm ReDoS Denial of Service Vulnerability

CVE-2025-48943 Overview

CVE-2025-48943 is a Regular Expression Denial of Service (ReDoS) vulnerability in vLLM, an inference and serving engine for large language models (LLMs). Authenticated users can crash the vLLM server by supplying an invalid regular expression through the structured output feature. The flaw affects versions from 0.8.0 up to but excluding 0.9.0. It is closely related to CVE-2025-48942, which covered the same crash pattern for JSON schema input. The vulnerability is classified as [CWE-248] Uncaught Exception and results in high availability impact.

Critical Impact
A network-adjacent attacker with low privileges can trigger an uncaught exception through malformed regex input, crashing the vLLM inference server and disrupting LLM services for all connected clients.

Affected Products

vLLM version 0.8.0
vLLM versions after 0.8.0 and prior to 0.9.0
vLLM structured output feature (regex guided decoding)

Discovery Timeline

2025-05-30 - CVE-2025-48943 published to NVD
2025-05-30 - GitHub Security Advisory GHSA-9hcf-v7m4-6m2j published
2025-05-30 - vLLM 0.9.0 released with fix in commit 08bf7840
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-48943

Vulnerability Analysis

vLLM exposes a structured output API that allows clients to constrain LLM generation with either a JSON schema or a regular expression. When a client submits a request with regex guided decoding, vLLM passes the pattern to the guided decoding backend (xgrammar or guidance) for compilation.

Invalid or malformed regular expressions raise exceptions during grammar construction. In vulnerable versions, these exceptions are not caught inside the request processing path. The uncaught exception propagates upward and terminates the vLLM engine process rather than being returned as a client-side error. Because vLLM serves multiple concurrent requests from a single engine process, the crash disrupts service for every connected client.

Root Cause

The root cause is missing validation and exception handling around grammar compilation in vllm/v1/engine/processor.py and vllm/v1/structured_output/backend_xgrammar.py. Regex and JSON schema inputs were compiled without wrapping the call in a try/except block that could translate failures into an HTTP 400 response. This falls under [CWE-248] Uncaught Exception.

Attack Vector

An authenticated user sends a structured output request containing a syntactically invalid or unsupported regex pattern to a vLLM endpoint such as /v1/completions or /v1/chat/completions. The engine attempts to compile the pattern, raises an exception in a code path that lacks handling, and terminates. All in-flight and subsequent requests fail until the engine restarts.

python

                validate_xgrammar_grammar(params)
                params.guided_decoding.backend = "xgrammar"
            except ValueError:
-                # The request includes some jsonschema feature(s) that
+                # The request either failed validation
+                # or includes some jsonschema feature(s) that
                # are not supported in xgrammar. Fall back to guidance.
+                validate_guidance_grammar(params, tokenizer=None)
                params.guided_decoding.backend = "guidance"
            # Remember that this backend was set automatically
            params.guided_decoding.backend_was_auto = True

Source: vLLM commit 08bf7840. The patch adds a fallback validation call so invalid grammars are surfaced as ValueError and returned as HTTP 400 responses instead of crashing the engine.

Detection Methods for CVE-2025-48943

Indicators of Compromise

Unexpected vLLM engine process termination followed by container or systemd restart events.
Client-side request timeouts or 5xx responses on /v1/completions and /v1/chat/completions endpoints during structured output usage.
Stack traces in vLLM logs referencing xgrammar, guidance, or guided_decoding immediately before shutdown.

Detection Strategies

Parse vLLM logs for uncaught exceptions raised from vllm/v1/structured_output/ modules and correlate with process exit events.
Track HTTP request payloads that include guided_regex fields with abnormal length, nested quantifiers, or invalid syntax.
Alert on repeated engine restarts within a short window from the same authenticated API key or source IP.

Monitoring Recommendations

Monitor vLLM engine uptime and restart counts through container orchestration metrics such as Kubernetes restartCount.
Capture inbound request bodies at an API gateway to retain regex patterns for post-incident analysis.
Emit availability alerts when the vLLM /health endpoint fails for consecutive probes.

How to Mitigate CVE-2025-48943

Immediate Actions Required

Upgrade vLLM to version 0.9.0 or later, which includes the fix from commit 08bf7840.
Restrict access to vLLM inference endpoints so that only authenticated, trusted clients can submit structured output requests.
Deploy an API gateway or reverse proxy that validates guided_regex and guided_json parameters before forwarding to vLLM.

Patch Information

The fix is delivered in vLLM 0.9.0 through pull request vllm-project/vllm#17623 and commit 08bf7840. The patch wraps grammar compilation in exception handling and returns HTTP 400 to the client instead of allowing the engine to terminate. Full details are available in the GitHub Security Advisory GHSA-9hcf-v7m4-6m2j.

Workarounds

Disable structured output features by rejecting requests that contain guided_regex or guided_json fields at the proxy layer if upgrading is not immediately possible.
Rate limit requests per API key on structured output endpoints to reduce blast radius from a single abusive client.
Run the vLLM engine under a process supervisor that restarts the service quickly, and place multiple replicas behind a load balancer to preserve availability.

bash

# Configuration example: upgrade vLLM to a patched release
pip install --upgrade "vllm>=0.9.0"

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