CVE-2026-55574: vLLM ReDoS Denial-of-Service Vulnerability in Structured Output Regex

Technical summary

CVE-2026-55574 is a regular expression denial-of-service (ReDoS) vulnerability in vLLM's structured_outputs.regex API parameter. The vulnerability stems from insufficient input validation on user-supplied regex strings before they reach the grammar compiler backends. In the xgrammar backend, the regex string passes through without any compilation timeout safeguard. In the outlines backend, validation checks for structural issues (lookarounds, backreferences) but omits complexity analysis, allowing patterns with nested quantifiers to bypass validation. Such patterns trigger exponential state-space expansion in the regex engine, causing the inference worker process to hang indefinitely. The root cause is the absence of either timeout enforcement or computational complexity analysis on regex patterns prior to compilation.

Business impact

Organizations deploying vLLM as an inference service face availability risk. A single malicious API request containing an adversarial regex can render an inference worker unresponsive, degrading or halting service for all users relying on that worker. In production environments running multiple inference tasks or serving multiple tenants, this becomes a targeted denial-of-service vector against model availability. For SaaS providers or enterprises offering LLM inference as an internal service, this vulnerability could be exploited to disrupt model inference pipelines. The impact is exacerbated in resource-constrained environments where worker recovery requires manual intervention.

Affected systems

vLLM versions prior to 0.24.0 are affected. Any deployment using the structured_outputs feature with a regex parameter is susceptible. Both the xgrammar and outlines grammar compiler backends are vulnerable, though through different validation gaps. Systems running vLLM 0.24.0 or later are not affected by this issue.

Exploitability

Exploitability is straightforward. The vulnerability requires only network access to the vLLM API and the ability to submit an inference request with the structured_outputs.regex parameter. No authentication bypass, privilege escalation, or complex payload engineering is necessary—a well-crafted regex pattern with nested quantifiers (such as (a+)+b) will trigger the hang. The CVSS vector (AV:N/AC:L/PR:N/UI:N) reflects this low barrier: the attack is network-accessible, requires no special conditions, and needs no user interaction. However, the attack is limited to denial-of-service; it does not achieve code execution, data exfiltration, or confidentiality/integrity compromise.

Remediation

Upgrade vLLM to version 0.24.0 or later. This release includes fixes to both the xgrammar and outlines backends that add timeout enforcement or complexity analysis to regex compilation. For organizations unable to upgrade immediately, the primary mitigation is to restrict API access—disable or revoke public/untrusted access to the structured_outputs API endpoint, and rely on authentication and rate-limiting at the API gateway level to reduce exposure to untrusted requests.

Patch guidance

Apply vLLM version 0.24.0 or later through your package manager (e.g., pip install --upgrade vllm). Verify the upgrade by checking the version reported by vLLM on startup. If running vLLM in containers, rebuild container images with the patched version and redeploy. No database migrations, configuration changes, or service restarts beyond the standard deployment process are required. Test the structured_outputs feature post-upgrade to confirm backward compatibility with your model serving workflows.

Detection guidance

Monitor inference worker logs for patterns of regex compilation timeouts or excessive CPU usage tied to specific inference requests. Alert on any inference request that includes the structured_outputs.regex parameter with suspicious patterns (nested quantifiers, repetitive escape sequences, or unusually long patterns). Network-level detection is limited, as the malicious payload is API-level; focus detection on vLLM application logs, worker metrics (CPU, memory, response times), and request logging that captures the regex parameter values. Inspect slow query logs or inference latency spikes correlating with specific API requests.

Why prioritize this

Although CVSS 7.5 (HIGH) reflects the network-accessible, unauthenticated nature of the attack, prioritization should account for deployment context. If vLLM is exposed to untrusted or public internet traffic, this is a critical priority—any user can hang workers on demand. If vLLM is internal-only or behind strong API authentication, priority can be moderate, allowing for scheduled maintenance windows. The lack of KEV status (not yet on CISA's Known Exploited Vulnerabilities list) suggests limited active exploitation in the wild, but the simplicity of the attack means this could change. Organizations with high-availability inference requirements should treat this as high priority regardless of KEV status.

Risk score, explained

The CVSS 7.5 HIGH score reflects network accessibility (AV:N), low attack complexity (AC:L), no privilege requirements (PR:N), and no user interaction (UI:N), combined with high availability impact (A:H). However, the score does not penalize the lack of confidentiality or integrity impact, which is appropriate for this attack. The risk in practice depends on whether vLLM is internet-facing, the sensitivity of model availability, and whether the organization has compensating controls (rate limiting, authentication, input validation) in place.

Frequently asked questions