vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the structured_outputs.regex parameter in vllm/v1/structured_output/backend_lm_format_enforcer.py is passed to lmformatenforcer.RegexParser without compile_regex_with_timeout or validation in validate_structured_output_request_lm_format_enforcer, allowing an unauthenticated /v1/completions request against the lm-format-enforcer backend to consume a CPU core and stall the structured-output engine path with a catastrophic regular expression. This issue is fixed in version 0.26.0.

Affected: PyPI: vllm

### Summary

The fix for `GHSA-rwxx-mrjm-wc2m` ("ReDoS via `structured_outputs.regex` compiled without timeout") wrapped the regex compile in the **xgrammar** and **outlines** backends with `compile_regex_with_timeout` (and, for outlines, `validate_regex_is_buildable`). The **lm-format-enforcer** backend was left unguarded: it compiles the attacker-supplied regex with no timeout and no buildability check. A single request with a catastrophic regex hangs the structured-output compile step and stalls the engine worker (denial of service).

### Affected code (HEAD d6d39c1)

`vllm/v1/structured_output/backend_lm_format_enforcer.py`: - line 110: `character_level_parser = lmformatenforcer.RegexParser(grammar_spec)` — builds an `interegular` FSM from the attacker regex synchronously, **no timeout**. - line 155: `validate_structured_output_request_lm_format_enforcer` returns immediately on `if so_params.regex:` — **no validation**.

Sibling backends that WERE patched by GHSA-rwxx: - `backend_xgrammar.py:92` → `compile_regex_with_timeout(...)`. - `backend_outlines.py:65` → `compile_regex_with_timeout(...)` (plus `validate_regex_is_buildable`).

lm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.

### Reproduction (runtime-verified against the sink)

The sink `lmformatenforcer.RegexParser(<regex>)` was exercised directly (this is exactly what the backend calls):

``` baseline '[0-9]{3}' -> 0.0002 s attacker…

Affected: PyPI: vllm

### Summary

The fix for `GHSA-rwxx-mrjm-wc2m` ("ReDoS via `structured_outputs.regex` compiled without timeout") wrapped the regex compile in the **xgrammar** and **outlines** backends with `compile_regex_with_timeout` (and, for outlines, `validate_regex_is_buildable`). The **lm-format-enforcer** backend was left unguarded: it compiles the attacker-supplied regex with no timeout and no buildability check. A single request with a catastrophic regex hangs the structured-output compile step and stalls the engine worker (denial of service).

### Affected code (HEAD d6d39c1)

`vllm/v1/structured_output/backend_lm_format_enforcer.py`: - line 110: `character_level_parser = lmformatenforcer.RegexParser(grammar_spec)` — builds an `interegular` FSM from the attacker regex synchronously, **no timeout**. - line 155: `validate_structured_output_request_lm_format_enforcer` returns immediately on `if so_params.regex:` — **no validation**.

Sibling backends that WERE patched by GHSA-rwxx: - `backend_xgrammar.py:92` → `compile_regex_with_timeout(...)`. - `backend_outlines.py:65` → `compile_regex_with_timeout(...)` (plus `validate_regex_is_buildable`).

lm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.

### Reproduction (runtime-verified against the sink)

The sink `lmformatenforcer.RegexParser(<regex>)` was exercised directly (this is exactly what the backend calls):

``` baseline '[0-9]{3}' -> 0.0002 s attacker…

sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 Apache Thrift: apache.com/apache/thrift: Apache Thrift: Out-of-bounds Read vulnerability thrift: org.apache.thrift/libthrift: github.com/apache/thrift: Apache Thrift: Denial of Service via improper handling of highly compressed data jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass thrift: github.com/apache/thrift: Apache Thrift: Denial of Service via integer overflow or wraparound libaom: libaom: heap buffer overflow in AV1 encoder first-pass stats buffer via LAP mode libaom: libaom: arbitrary address write via SVC layer context OOB and cyclic refresh map pointer hijack libaom: libaom: heap-buffer-overflow read via missing bounds check in ctrl_set_layer_id libaom: libaom: remote code execution via SVC layer context handling with attacker-controlled frames ray: Ray: Remote code execution via unsafe deserialization in WebDataset reader FFmpeg: FFmpeg: Memory corruption via crafted RASC video stream pytorch-lightning: PyTorch Lightning: Remote code execution via malicious checkpoint files com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: jackson-databind: @JsonIgnore bypass in Java Records FFmpeg: FFmpeg: Arbitrary code execution, information disclosure, or denial of service via crafted ADX/AAX audio files com.fasterxml.jackson.core…