Średnia

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

  • Ujawniono: 04.09.2026
  • Aktualizacja: 11.10.2026 15:18

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)

End-to-end: start vllm serve <model> --structured-outputs-config '{"backend":"lm-format-enforcer"}', then POST /v1/completions with {"structured_outputs":{"regex":"(a{1,300}){300}"}, ...}. The request never returns; because grammar compile runs in the engine's structured-output path, concurrent requests stall = worker-level DoS. The identical request against the outlines backend is bounded by compile_regex_with_timeout and returns a clean error.

Impact

Unauthenticated denial of service (vLLM ships with no authentication by default). One request pegs a CPU core and blocks the structured-output engine path.

Reachability precondition: the operator must have selected backend=lm-format-enforcer via --structured-outputs-config (the default is auto → xgrammar). This is the same opt-in tier as the outlines backend that GHSA-rwxx already covered.

Suggested remediation

Route the lm-format-enforcer regex compile (backend_lm_format_enforcer.py:110) through the same compile_regex_with_timeout guard already applied to the xgrammar and outlines backends, and reject un-buildable / oversized patterns in validate_structured_output_request_lm_format_enforcer.

Czego dotyczy

Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.

PlatformaPaczkaPodatne wersjePoprawka w wersji
Python (PyPI) vllm < 0.26.0 0.26.0

Odnośniki

Ocena CVSS 5.3/10
Wektor CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Słabość (CWE)
CWE-1333, CWE-400
Platforma
Python (PyPI)
Paczka
vllm
Ujawniono
04.09.2026
Aktualizacja
11.10.2026 15:18

Źródła i licencje

OSV / GitHub Advisory Database - PYSEC-2026-3933 - PyPA Advisory Database; CC BY 4.0

OSV / GitHub Advisory Database - GHSA-48jh-3gj7-fg8v - CC BY 4.0

Historia podatności: vllm

Wszystkie opisane podatności tej paczki (Python (PyPI)), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.

Wszystkie (94) w archiwum
Wszystkich wpisów
94
Pierwsza → ostatnia
09.2024 10.2026
Bez poprawki
5
Wykorzystywana w atakach
0

Rozkład istotności

  • Krytyczna 9
  • Wysoka 23
  • Średnia 47
  • Niska 4
  • Nieoceniona 11

Ujawnienia w latach

  1. 2024: 2
  2. 2025: 30
  3. 2026: 62
Istotność:
  1. vLLM: ReDoS via structured_outputs.regex in the lm-format-enforcer backend (no compile timeout) — missed sibling of GHSA-rwxx-mrjm-wc2m ten wpis
    Średnia · 5.3 CVE-2026-73556 < 0.26.0 0.26.0
  2. Wysoka · 7.5 CVE-2026-54234 >= 0.17.1, < 0.24.0 0.24.0
  3. Wysoka CVE-2026-55514 >= 0.12.0, < 0.24.0 0.24.0
  4. Krytyczna · 9.1 CVE-2026-48746 >= 0.3.0, < 0.22.0 0.22.0
  5. Krytyczna · 9.8 CVE-2026-22778 >= 0.8.3, < 0.14.1 0.14.1
  6. Wysoka · 8.8 CVE-2026-22807 >= 0.10.1, < 0.14.0 0.14.0
  7. Wysoka · 8.8 CVE-2026-56340 >= 0.10.2, < 0.13.0 0.13.0
  8. Wysoka · 6.5 CVE-2025-62372 >= 0.5.5, < 0.11.1 0.11.1
  9. Wysoka · 8.8 CVE-2025-62164 >= 0.10.2, < 0.11.1 0.11.1
  10. Wysoka · 7.5 CVE-2025-59425 < 0.11.0 0.11.0
Pokaż więcej (13) Widać 20 z 33

Dowiedz się, które podatności dotyczą Twojej aplikacji

Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.

Podłącz swoją aplikację
Newsletter DockRay

Bezpieczeństwo aplikacji w Twojej skrzynce

Najważniejsze podatności, konkretne zalecenia i praktyczne wskazówki dla Twoich aplikacji. Wybierz technologie i śledź to, co ma znaczenie dla Twojego projektu.

  • Codzienne zestawienie nowych podatności, także krytycznych.
  • Powiadomienia o ważnych aktualizacjach.
  • Praktyczne porady o bezpieczeństwie i monitoringu aplikacji.

Pozostaw puste, aby otrzymywać informacje o wszystkich technologiach.

Zapis jest bezpłatny. Wypiszesz się jednym kliknięciem w wiadomości.