<?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://cve.radiocsirt.org</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>Fri, 09 Oct 2026 00:14:08 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-328553</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-328553</link>
      <description>EUVD-2026-328553</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-328553</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45617</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45617</link>
      <description>&lt;p&gt;LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the built-in strip_html filter uses a regex containing four flawed lazy-quantified alternatives, leading to ReDoS via quadratic backtracking. When the input contains many &amp;lt;script, &amp;lt;style, or &amp;lt;!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request (&amp;#39;&amp;lt;script&amp;#39;.repeat(50000)) stalls the process for ~10 seconds; cost grows quadratically with input size. The default memoryLimit: Infinity does not bound regex CPU, and even when configured strip_html only charges str.length to the limit — the regex itself runs unbounded.  A single unauthenticated request containing crafted untrusted input can cause severe event-loop blocking and CPU amplification that saturates Node.js workers while bypassing memoryLimit protections. This issue has been fixed in version 10.26.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the built-in strip_html filter uses a regex containing four flawed lazy-quantified alternatives, leading to ReDoS via quadratic backtracking. When the input contains many &amp;lt;script, &amp;lt;style, or &amp;lt;!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request (&amp;#39;&amp;lt;script&amp;#39;.repeat(50000)) stalls the process for ~10 seconds; cost grows quadratically with input size. The default memoryLimit: Infinity does not bound regex CPU, and even when configured strip_html only charges str.length to the limit — the regex itself runs unbounded.  A single unauthenticated request containing crafted untrusted input can cause severe event-loop blocking and CPU amplification that saturates Node.js workers while bypassing memoryLimit protections. This issue has been fixed in version 10.26.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45617</guid>
    </item>
    <item>
      <title>GHSA-r7g9-xpmj-5fcq — LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-r7g9-xpmj-5fcq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: liquidjs&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The built-in `strip_html` filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many `&amp;lt;script`, `&amp;lt;style`, or `&amp;lt;!--` opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request (`&amp;#39;&amp;lt;script&amp;#39;.repeat(50000)`) stalls the process for ~10 seconds; cost grows quadratically with input size. The default `memoryLimit: Infinity` does not bound regex CPU, and even when configured `strip_html` only charges `str.length` to the limit — the regex itself runs unbounded.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The vulnerable filter is at `src/filters/html.ts:45-49`:&lt;/p&gt;
&lt;p&gt;```ts
export function strip_html (this: FilterImpl, v: string) {
  const str = stringify(v)
  this.context.memoryLimit.use(str.length)
  return str.replace(/&amp;lt;script[\s\S]*?&amp;lt;\/script&amp;gt;|&amp;lt;style[\s\S]*?&amp;lt;\/style&amp;gt;|&amp;lt;.*?&amp;gt;|&amp;lt;!--[\s\S]*?--&amp;gt;/g, &amp;#39;&amp;#39;)
}
```&lt;/p&gt;
&lt;p&gt;The regex contains four lazy patterns:
1. `&amp;lt;script[\s\S]*?&amp;lt;\/script&amp;gt;`
2. `&amp;lt;style[\s\S]*?&amp;lt;\/style&amp;gt;`
3. `&amp;lt;.*?&amp;gt;`
4. `&amp;lt;!--[\s\S]*?--&amp;gt;`&lt;/p&gt;
&lt;p&gt;For an input like `&amp;#39;&amp;lt;script&amp;#39;.repeat(N)`, the engine encounters N starting `&amp;lt;` positions. At each one it must lazily expand `[\s\S]*?` (and `.*?`) all the way to end-of-input searching for a closer that never appears, then fail and backtrack. Because each of the O(N) starts performs O(N) lazy-expansion work, total work is O(N²).&lt;/p&gt;
&lt;p&gt;Reachability:
1. `strip_html` is a default-registered filter (exported from `src/filters/html.ts`, wired up via `src/fi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: liquidjs&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The built-in `strip_html` filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many `&amp;lt;script`, `&amp;lt;style`, or `&amp;lt;!--` opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request (`&amp;#39;&amp;lt;script&amp;#39;.repeat(50000)`) stalls the process for ~10 seconds; cost grows quadratically with input size. The default `memoryLimit: Infinity` does not bound regex CPU, and even when configured `strip_html` only charges `str.length` to the limit — the regex itself runs unbounded.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The vulnerable filter is at `src/filters/html.ts:45-49`:&lt;/p&gt;
&lt;p&gt;```ts
export function strip_html (this: FilterImpl, v: string) {
  const str = stringify(v)
  this.context.memoryLimit.use(str.length)
  return str.replace(/&amp;lt;script[\s\S]*?&amp;lt;\/script&amp;gt;|&amp;lt;style[\s\S]*?&amp;lt;\/style&amp;gt;|&amp;lt;.*?&amp;gt;|&amp;lt;!--[\s\S]*?--&amp;gt;/g, &amp;#39;&amp;#39;)
}
```&lt;/p&gt;
&lt;p&gt;The regex contains four lazy patterns:
1. `&amp;lt;script[\s\S]*?&amp;lt;\/script&amp;gt;`
2. `&amp;lt;style[\s\S]*?&amp;lt;\/style&amp;gt;`
3. `&amp;lt;.*?&amp;gt;`
4. `&amp;lt;!--[\s\S]*?--&amp;gt;`&lt;/p&gt;
&lt;p&gt;For an input like `&amp;#39;&amp;lt;script&amp;#39;.repeat(N)`, the engine encounters N starting `&amp;lt;` positions. At each one it must lazily expand `[\s\S]*?` (and `.*?`) all the way to end-of-input searching for a closer that never appears, then fail and backtrack. Because each of the O(N) starts performs O(N) lazy-expansion work, total work is O(N²).&lt;/p&gt;
&lt;p&gt;Reachability:
1. `strip_html` is a default-registered filter (exported from `src/filters/html.ts`, wired up via `src/fi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-r7g9-xpmj-5fcq</guid>
    </item>
  </channel>
</rss>
