<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T19:30:14.357630+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2026-73556</id>
    <title>CVE-2026-73556 — vLLM: ReDoS via structured_outputs.regex in the lm-format-enforcer backend (no compile timeout) — missed sibling of CVE…</title>
    <updated>2026-10-02T19:30:14.396692+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> vllm-project vllm</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-73556"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-48jh-3gj7-fg8v</id>
    <title>GHSA-48jh-3gj7-fg8v — vLLM: ReDoS via structured_outputs.regex in the lm-format-enforcer backend (no compile timeout) — missed sibling of GHS…</title>
    <updated>2026-10-02T19:30:14.396776+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: vllm</p>
<p>### Summary</p>
<p>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).</p>
<p>### Affected code (HEAD d6d39c1)</p>
<p>`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**.</p>
<p>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`).</p>
<p>lm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.</p>
<p>### Reproduction (runtime-verified against the sink)</p>
<p>The sink `lmformatenforcer.RegexParser(&lt;regex&gt;)` was exercised directly (this is exactly what the backend calls):</p>
<p>```
baseline  '[0-9]{3}'          -&gt; 0.0002 s
attacker…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-48jh-3gj7-fg8v"/>
  </entry>
</feed>
