<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 28 Sep 2026 14:39:24 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-73556</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-73556</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-73556</guid>
    </item>
    <item>
      <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>
      <link>https://vulnerability.circl.lu/vuln/ghsa-48jh-3gj7-fg8v</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The fix for `GHSA-rwxx-mrjm-wc2m` (&amp;#34;ReDoS via `structured_outputs.regex` compiled without timeout&amp;#34;) 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).&lt;/p&gt;
&lt;p&gt;### Affected code (HEAD d6d39c1)&lt;/p&gt;
&lt;p&gt;`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**.&lt;/p&gt;
&lt;p&gt;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`).&lt;/p&gt;
&lt;p&gt;lm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.&lt;/p&gt;
&lt;p&gt;### Reproduction (runtime-verified against the sink)&lt;/p&gt;
&lt;p&gt;The sink `lmformatenforcer.RegexParser(&amp;lt;regex&amp;gt;)` was exercised directly (this is exactly what the backend calls):&lt;/p&gt;
&lt;p&gt;```
baseline  &amp;#39;[0-9]{3}&amp;#39;          -&amp;gt; 0.0002 s
attacker…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The fix for `GHSA-rwxx-mrjm-wc2m` (&amp;#34;ReDoS via `structured_outputs.regex` compiled without timeout&amp;#34;) 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).&lt;/p&gt;
&lt;p&gt;### Affected code (HEAD d6d39c1)&lt;/p&gt;
&lt;p&gt;`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**.&lt;/p&gt;
&lt;p&gt;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`).&lt;/p&gt;
&lt;p&gt;lm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.&lt;/p&gt;
&lt;p&gt;### Reproduction (runtime-verified against the sink)&lt;/p&gt;
&lt;p&gt;The sink `lmformatenforcer.RegexParser(&amp;lt;regex&amp;gt;)` was exercised directly (this is exactly what the backend calls):&lt;/p&gt;
&lt;p&gt;```
baseline  &amp;#39;[0-9]{3}&amp;#39;          -&amp;gt; 0.0002 s
attacker…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-48jh-3gj7-fg8v</guid>
    </item>
    <item>
      <title>PYSEC-2026-3933 — vLLM: ReDoS via structured_outputs.regex in the lm-format-enforcer backend (no compile timeout) — missed sibling of GHS…</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-3933</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The fix for `GHSA-rwxx-mrjm-wc2m` (&amp;#34;ReDoS via `structured_outputs.regex` compiled without timeout&amp;#34;) 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).&lt;/p&gt;
&lt;p&gt;### Affected code (HEAD d6d39c1)&lt;/p&gt;
&lt;p&gt;`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**.&lt;/p&gt;
&lt;p&gt;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`).&lt;/p&gt;
&lt;p&gt;lm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.&lt;/p&gt;
&lt;p&gt;### Reproduction (runtime-verified against the sink)&lt;/p&gt;
&lt;p&gt;The sink `lmformatenforcer.RegexParser(&amp;lt;regex&amp;gt;)` was exercised directly (this is exactly what the backend calls):&lt;/p&gt;
&lt;p&gt;```
baseline  &amp;#39;[0-9]{3}&amp;#39;          -&amp;gt; 0.0002 s
attacker…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: vllm&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The fix for `GHSA-rwxx-mrjm-wc2m` (&amp;#34;ReDoS via `structured_outputs.regex` compiled without timeout&amp;#34;) 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).&lt;/p&gt;
&lt;p&gt;### Affected code (HEAD d6d39c1)&lt;/p&gt;
&lt;p&gt;`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**.&lt;/p&gt;
&lt;p&gt;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`).&lt;/p&gt;
&lt;p&gt;lm-format-enforcer uses the same `interegular` DFA-construction primitive the advisory cites for the outlines backend.&lt;/p&gt;
&lt;p&gt;### Reproduction (runtime-verified against the sink)&lt;/p&gt;
&lt;p&gt;The sink `lmformatenforcer.RegexParser(&amp;lt;regex&amp;gt;)` was exercised directly (this is exactly what the backend calls):&lt;/p&gt;
&lt;p&gt;```
baseline  &amp;#39;[0-9]{3}&amp;#39;          -&amp;gt; 0.0002 s
attacker…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-3933</guid>
    </item>
    <item>
      <title>RHSA-2026:68699 — Red Hat Security Advisory: Red Hat AI Inference Server 3.3.7 (CUDA)</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2026:68699</link>
      <description>&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2026:68699</guid>
    </item>
  </channel>
</rss>
