vLLM: ReDoS via structured_outputs.regex in the lm-format-enforcer backend (no compile timeout) — missed sibling of GHSA-rwxx-mrjm-wc2m

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  '(a{1,300}){300}'   -> DID NOT COMPLETE in 20 s (one core pegged at 100% in interegular FSM construction)