CVE-2026-55574: vLLM: unbounded regex compile hangs inference worker (ReDoS)
GHSA-rwxx-mrjm-wc2m HIGHPrior to 0.24.0, vLLM's structured_outputs.regex parameter passes attacker-controlled regular expressions straight into the grammar compiler with no compilation timeout, and neither the xgrammar nor outlines backend performs complexity analysis on nested quantifiers, so a single crafted request triggers catastrophic backtracking-style exponential state-space expansion and hangs the worker indefinitely. There's no CVSS/EPSS scoring yet and no public exploit or Nuclei template, so exploitation likelihood is currently unquantified, but the bug requires only unauthenticated API access to any endpoint that exposes structured-output/regex-constrained generation — a common pattern for JSON-mode and tool-calling deployments. The blast radius depends on how many downstream services expose this parameter to end users versus keep it server-side only; vLLM is a widely deployed inference engine so any multi-tenant or public-facing serving stack accepting user-supplied regex/grammar constraints is at risk of a low-effort denial of service. Patch to vLLM 0.24.0 immediately; until then, strip or hard-validate any user-controlled regex/grammar input before it reaches structured_outputs, and monitor for workers stuck at 100% CPU with no token throughput as a detection signal.
What is the risk?
This is a denial-of-service vulnerability (CWE-1333, ReDoS-class) rather than a data-confidentiality or code-execution issue, so worst-case impact is service unavailability rather than data breach. Exploitability is low-effort once an attacker can reach the structured_outputs.regex parameter — it requires no authentication bypass, no special privileges beyond normal API access, and no chained vulnerabilities, just a single adversarial pattern with nested quantifiers. No CVSS score, EPSS, or KEV listing is available yet, and there's no public exploit or scanner template, so real-world exploitation activity is currently unknown; treat as moderate-priority given ease of exploitation but unconfirmed prevalence. Risk is materially higher for any deployment that exposes structured-output/grammar constraints directly to external or semi-trusted users (e.g., a hosted JSON-mode API, a multi-tenant inference gateway, or an agent framework that lets end users specify output schemas).
How does the attack unfold?
What systems are affected?
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade to vLLM 0.24.0 or later, which adds compilation timeout/complexity guards to the structured-output regex path. Until patched, do not expose the structured_outputs.regex parameter (or any wrapper API that maps to it) to untrusted or external users — restrict grammar/regex definition to server-side, developer-controlled schemas only. As a stopgap, front vLLM with a request-level timeout and per-worker circuit breaker that kills and restarts hung inference processes, and add input validation that rejects regex patterns with nested quantifiers or excessive repetition constructs before they reach the compiler. Detection: monitor for individual vLLM worker processes pegged at high CPU with no corresponding token generation progress, and alert on requests containing regex-like fields with unusually long or deeply nested patterns.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-55574?
Prior to 0.24.0, vLLM's structured_outputs.regex parameter passes attacker-controlled regular expressions straight into the grammar compiler with no compilation timeout, and neither the xgrammar nor outlines backend performs complexity analysis on nested quantifiers, so a single crafted request triggers catastrophic backtracking-style exponential state-space expansion and hangs the worker indefinitely. There's no CVSS/EPSS scoring yet and no public exploit or Nuclei template, so exploitation likelihood is currently unquantified, but the bug requires only unauthenticated API access to any endpoint that exposes structured-output/regex-constrained generation — a common pattern for JSON-mode and tool-calling deployments. The blast radius depends on how many downstream services expose this parameter to end users versus keep it server-side only; vLLM is a widely deployed inference engine so any multi-tenant or public-facing serving stack accepting user-supplied regex/grammar constraints is at risk of a low-effort denial of service. Patch to vLLM 0.24.0 immediately; until then, strip or hard-validate any user-controlled regex/grammar input before it reaches structured_outputs, and monitor for workers stuck at 100% CPU with no token throughput as a detection signal.
Is CVE-2026-55574 actively exploited?
No confirmed active exploitation of CVE-2026-55574 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-55574?
Upgrade to vLLM 0.24.0 or later, which adds compilation timeout/complexity guards to the structured-output regex path. Until patched, do not expose the structured_outputs.regex parameter (or any wrapper API that maps to it) to untrusted or external users — restrict grammar/regex definition to server-side, developer-controlled schemas only. As a stopgap, front vLLM with a request-level timeout and per-worker circuit breaker that kills and restarts hung inference processes, and add input validation that rejects regex patterns with nested quantifiers or excessive repetition constructs before they reach the compiler. Detection: monitor for individual vLLM worker processes pegged at high CPU with no corresponding token generation progress, and alert on requests containing regex-like fields with unusually long or deeply nested patterns.
What systems are affected by CVE-2026-55574?
This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks, RAG pipelines.
What is the CVSS score for CVE-2026-55574?
CVE-2026-55574 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.32%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029 Denial of AI Service AML.T0034.001 Resource-Intensive Queries AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, the structured_outputs.regex API parameter passes a user-supplied regular expression string directly to the grammar compiler backends with no compilation timeout; in the xgrammar backend the string reaches the regex compiler with no guard, and in the outlines backend the validation step blocks structural issues such as lookarounds and backreferences but performs no complexity analysis, so a pattern with nested quantifiers passes all checks and causes exponential state-space expansion, allowing a single request containing an adversarial regex to hang an inference worker indefinitely and deny service. This issue is fixed in version 0.24.0.
Exploitation Scenario
An adversary identifies a public-facing service built on vLLM that exposes structured/JSON-mode output where the schema or regex constraint is derived from user input (for example, a SaaS app letting users define a custom output format for an LLM feature). The attacker submits a single inference request with a maliciously crafted regex containing nested quantifiers (e.g., patterns resembling (a+)+b) as the structured_outputs.regex value. The xgrammar or outlines backend accepts the pattern without complexity analysis, the grammar compiler begins exponential state-space expansion, and the worker thread hangs indefinitely processing that one request. If the attacker repeats this across multiple requests or worker replicas, they can exhaust the entire inference pool, denying service to all legitimate users of that endpoint without needing valid credentials beyond normal API access.
Weaknesses (CWE)
CWE-1333 Inefficient Regular Expression Complexity
Primary
CWE-1333 Inefficient Regular Expression Complexity
Primary
CWE-1333 Inefficient Regular Expression Complexity CWE-1333 — Inefficient Regular Expression Complexity: The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.
- [Architecture and Design] Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
- [System Configuration] Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H References
- github.com/advisories/GHSA-rwxx-mrjm-wc2m
- github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-2304.yaml
- nvd.nist.gov/vuln/detail/CVE-2026-55574
- github.com/vllm-project/vllm/commit/2b3006076c5e9bc4cda9e03e3641388de3c5c286
- github.com/vllm-project/vllm/pull/45118
- github.com/vllm-project/vllm/security/advisories/GHSA-rwxx-mrjm-wc2m
Timeline
Related Vulnerabilities
CVE-2025-57809 7.5 xgrammar: uncontrolled recursion in grammar parsing causes DoS
Same package: xgrammar CVE-2026-25048 7.5 xgrammar: security flaw enables exploitation
Same package: xgrammar CVE-2025-32381 6.5 xgrammar: unbounded grammar cache causes LLM server DoS
Same package: xgrammar CVE-2025-58446 xgrammar: DoS via oversized JSON schema grammar parsing
Same package: xgrammar CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same attack type: DoS