CVE-2026-55574: 
NixOS vulnerability analysis and mitigation

CVE-2026-55574 is a Regular Expression Denial of Service (ReDoS) vulnerability in vLLM, a high-throughput inference and serving engine for large language models. The flaw exists in the structured_outputs.regex API parameter, which passes user-supplied regular expressions directly to grammar compiler backends (xgrammar and outlines) without any compilation timeout or complexity analysis. All vLLM versions prior to 0.24.0 are affected. The vulnerability was published on July 6, 2026, with the security advisory (GHSA-rwxx-mrjm-wc2m) originally published July 2, 2026. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory, Red Hat).

The root cause is classified as CWE-1333 (Inefficient Regular Expression Complexity), corresponding to CAPEC-492 (Regular Expression Exponential Blowup). In the xgrammar backend, backend_xgrammar.py:91 calls self.compiler.compile_regex(grammar_spec) with no timeout guard. In the outlines backend, validate_regex_is_buildable() in backend_outlines.py:299–330 performs only structural checks (blocking lookarounds and backreferences via sre_parse.parse() and _check_unsupported()) but performs no complexity analysis, allowing patterns with nested quantifiers such as (a+)+b to pass all validation and trigger exponential DFA state-space expansion during compilation at backend_outlines.py:64. An unauthenticated remote attacker can submit a single crafted API request with an adversarial regex to hang an inference worker indefinitely (GitHub Advisory, Patch Commit).

Successful exploitation results in a complete denial of service for the targeted vLLM inference worker, which hangs indefinitely and becomes unable to serve any further requests. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. In multi-tenant or production LLM serving environments, a single malicious request can take down an inference worker, disrupting all users relying on that instance (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.29–0.324%, placing it in the 25th percentile for exploitation likelihood within 30 days (GitHub Advisory). Despite the low EPSS, the attack requires no authentication, no user interaction, and no special privileges, making it trivially exploitable by any network-accessible attacker against unpatched instances.

1. Reconnaissance: Identify internet-facing or network-accessible vLLM instances running versions prior to 0.24.0 that expose the structured outputs API endpoint.
2. Craft adversarial regex: Construct a regular expression with nested quantifiers that causes exponential DFA state-space expansion, such as (a+)+b or more complex variants like (a|aa)+b.
3. Submit malicious request: Send an HTTP API request to the vLLM inference endpoint with the structured_outputs.regex parameter set to the adversarial pattern, e.g.:

   {
     "prompt": "Generate text",
     "guided_regex": "(a+)+b"
   }

4. Trigger compiler hang: The adversarial regex is passed without timeout to compile_regex() (xgrammar) or oc.Index() (outlines), causing the regex compiler to enter exponential state-space expansion and hang indefinitely.
5. Denial of service achieved: The inference worker thread is blocked indefinitely, rendering the vLLM instance unable to process any further requests (GitHub Advisory, Patch Commit).

• Network: Unusual or repeated HTTP requests to the vLLM inference API endpoint containing guided_regex or structured_outputs.regex parameters with patterns featuring nested quantifiers (e.g., (a+)+, (a|aa)+).
• Process: vLLM inference worker process consuming 100% CPU on a single core for an extended period without completing a request; worker threads stuck in regex compilation functions (compile_regex, oc.Index).
• Logs: vLLM server logs showing requests that never complete or time out; absence of response log entries for requests that were received; Python thread pool executor threads remaining active indefinitely.
• Application Behavior: Inference worker becomes unresponsive to new requests; health check endpoints stop responding; GPU utilization drops to near zero while CPU remains pegged on the affected worker.

Upgrade vLLM to version 0.24.0 or later, which introduces the compile_regex_with_timeout() utility that wraps both compile_regex() (xgrammar) and oc.Index() (outlines) calls in a ThreadPoolExecutor with a configurable deadline, defaulting to 5 seconds via the VLLM_REGEX_COMPILATION_TIMEOUT_S environment variable (Patch Commit). As a defense-in-depth measure, the timeout can be tuned via VLLM_REGEX_COMPILATION_TIMEOUT_S (set to 0 to disable, not recommended in production). Organizations unable to upgrade immediately should consider restricting access to the structured outputs API to trusted clients only, or implementing an API gateway that validates and rejects regex patterns with nested quantifiers before they reach vLLM (GitHub Advisory).

Red Hat tracked the vulnerability as high severity in their Bugzilla system (Bug 2497509) and published a CVE advisory page (Red Hat, Red Hat Bugzilla). The advisory was coordinated by jperezdealgaba and reported by brodmart, with the fix co-authored by Harry Mellor from the vLLM project team (Patch Commit). No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability database aggregation.