vLLM structured outputs: one regex can freeze an inference worker
A July 2026 advisory shows vLLM's structured-outputs regex parameter compiled user patterns with no timeout, letting a single crafted request hang a worker and deny service. Fixed in 0.24.0.
What is this?
On July 6, 2026, a security advisory was published for vLLM, one of the most widely deployed open-source inference and serving engines for large language models. The issue is a denial-of-service weakness in the structured-outputs feature: the API parameter that lets a caller constrain a model’s output to match a regular expression handed that user-supplied pattern straight to the grammar compiler with no time or complexity limit. A single request carrying a malicious pattern could pin an inference worker indefinitely. It is classed as an inefficient-regular-expression-complexity flaw (CWE-1333), better known as ReDoS, and it affects every version prior to 0.24.0, where it is fixed.
This is not a prompt-level attack and not a model jailbreak. It is a classic serving-layer availability bug that happens to live in an LLM-specific feature, which is exactly the kind of surface that grows as teams wire structured decoding into production APIs.
How it works
Structured outputs let an application force a model to emit text conforming to a schema — JSON, a grammar, or a raw regular expression — by constraining the decoder at each token. To do that, the chosen regex has to be compiled into a state machine that the sampler consults.
In the affected versions, that compilation step ran without a guard. In the xgrammar backend, the pattern reached the regex compiler directly. In the outlines backend, validation rejected some structural constructs such as lookarounds and backreferences, but it did no complexity analysis — so a pattern built from nested quantifiers passed every check and then blew up. Certain regex shapes cause the compiler to explore an exponential number of states, so a short, innocuous-looking string can translate into effectively unbounded work. Because the request is accepted over the network with no authentication and the compilation happens before any generation, one crafted call is enough to hang the worker and starve every legitimate request routed to it. The reported impact is on availability only — no code execution, no data disclosure — with a network attack vector and no privileges required. We are deliberately not reproducing a triggering pattern here; the mechanism is the point, not a ready-to-fire payload.
Why it matters
vLLM sits at the center of a great many self-hosted and enterprise LLM stacks, frequently behind an internal gateway that trusts its callers. Structured outputs are a popular way to make model responses machine-parseable, so the vulnerable parameter is not an obscure corner — it is a feature people reach for precisely in the automated, high-throughput pipelines where an unnoticed hang does the most damage. In a shared multi-tenant deployment, a single tenant able to set the regex can degrade service for everyone on the same worker pool, and an exposed endpoint turns a one-line request into a cheap outage. It is a useful reminder that the LLM serving layer inherits every ordinary web-service risk in addition to the model-specific ones. Related availability weaknesses in the same engine — from an audio-upload memory-exhaustion bug to the broader serving-layer attack surface — point at the same lesson.
Defenses
Upgrade vLLM to 0.24.0 or later. This is the primary and complete fix: the patch adds a bounded compilation step so a hostile pattern fails fast instead of hanging. The advisory also documents a compilation-timeout control (VLLM_REGEX_COMPILATION_TIMEOUT_S, defaulting to five seconds) that raises an error rather than blocking forever, giving you a value you can log and alert on.
Beyond patching, treat the regex parameter as untrusted input. If your application does not need caller-supplied regular expressions, disable or hard-code the structured-outputs pattern rather than passing user values through. Where you must accept them, validate pattern length and complexity before compilation and reject nested quantifiers. Do not expose the inference endpoint directly; require authentication, and apply per-caller rate limits so a single client cannot monopolize workers.
For detection, watch for inference workers that stop responding or spike CPU while compiling, and monitor for compilation-timeout errors once the fix is in place. Standard process tools — top/htop for stuck workers, tracing a suspect process to see whether it is stuck in regex compilation — will surface an attempt in progress.
Status
| Item | Detail |
|---|---|
| Affected | vLLM, all versions prior to 0.24.0 |
| Fixed in | vLLM 0.24.0 (PR #45118) |
| Weakness | CWE-1333, Inefficient Regular Expression Complexity (ReDoS) |
| Impact | Denial of service — availability only; unauthenticated, network, no privileges |
| Severity | CVSS 4.0 8.7 (High, CNA) / CVSS 3.1 7.5 (High, NVD); site rating: medium |
| Reference | CVE-2026-55574 (published 2026-07-06); advisory GHSA-rwxx-mrjm-wc2m |