CVE-2026-55574: vLLM: unbounded regex compile hangs inference worker (ReDoS)

GHSA-rwxx-mrjm-wc2m HIGH
Published July 6, 2026
CISO Take

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.

Sources: NVD GitHub Advisory ATLAS

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?

Initial Access
Adversary sends an inference request to a public-facing vLLM endpoint that accepts a user-influenced structured_outputs.regex parameter.
AML.T0049
Adversarial Input Crafting
Attacker embeds a regex pattern with nested quantifiers designed to trigger exponential state-space expansion in the grammar compiler.
AML.T0034.001
Resource Exhaustion
The xgrammar or outlines backend compiles the pattern with no timeout or complexity check, causing the worker thread to hang indefinitely on that single request.
Impact
The hung worker becomes unavailable for other requests; repeating the request across replicas can deny service to all users of the inference endpoint.
AML.T0029

What systems are affected?

Package Ecosystem Vulnerable Range Patched
vLLM pip < 0.24.0 0.24.0
89.7K 128 dependents Pushed today 25% patched ~52d to patch Full package profile →
XGrammar pip No patch
1.8K 13 dependents Pushed 2d ago 80% patched ~40d to patch Full package profile →

How severe is it?

CVSS 3.1
7.5 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 25% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR None
UI None
S Unchanged
C None
I None
A High

What should I do?

1 step
  1. 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?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

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:

ISO 42001
A.6.2.4 - AI system operation and monitoring
NIST AI RMF
MAP-2.3 / MEASURE-2.7 - AI system resilience to malicious or unintentional inputs
OWASP LLM Top 10
LLM10 - Unbounded Consumption

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

model servingagent frameworksRAG pipelines

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service
AML.T0034.001 Resource-Intensive Queries
AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.6.2.4
NIST AI RMF: MAP-2.3 / MEASURE-2.7
OWASP LLM Top 10: LLM10

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: 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

Timeline

Published
July 6, 2026
Last Modified
July 17, 2026
First Seen
July 6, 2026

Related Vulnerabilities