PYSEC-2026-2304: vLLM: ReDoS via structured_outputs.regex compiled without timeout in xgrammar and outlines backends
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, the structuredoutputs.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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
vLLMto a version that resolves this vulnerability.Fixed in 0.24.0
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service issue?
vLLM deployments running versions before 0.24.0 are exposed if they accept user-controlled values for the structured_outputs.regex API parameter. A single adversarial request can hang an inference worker indefinitely.
What does an attacker need to exploit it?
The attacker needs network access to an API path that allows them to supply a structured_outputs.regex value. No privileges or user interaction are required.
Are both supported grammar compiler backends affected?
Yes. In the xgrammar backend, the supplied regex reaches the compiler without a guard; in the outlines backend, patterns with nested quantifiers can pass structural validation and trigger exponential state-space expansion.
How can I determine whether my service is vulnerable?
Check whether vLLM is older than 0.24.0 and whether requests can provide the structured_outputs.regex parameter. Services meeting both conditions should be treated as affected.
What is the available remediation?
Upgrade vLLM to version 0.24.0, which fixes the issue.