GHSA-r7g9-xpmj-5fcq: LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex
Summary
The built-in strip_html filter in liquidjs uses a regex containing four lazy-quantified alternatives. When the input contains many <script, <style, or <!-- opener tokens without matching closers, the V8 regex engine performs O(N²) backtracking, blocking the Node.js event loop. A single ~350 KB request ('<script'.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.
Details
The vulnerable filter is at src/filters/html.ts:45-49:
export function strip_html (this: FilterImpl, v: string) {
const str = stringify(v)
this.context.memoryLimit.use(str.length)
return str.replace(/<script[\s\S]*?<\/script>|<style[\s\S]*?<\/style>|<.*?>|<!--[\s\S]*?-->/g, '')
}
The regex contains four lazy patterns:
1. <script[\s\S]*?<\/script>
2. <style[\s\S]*?<\/style>
3. <.*?>
4. <!--[\s\S]*?-->
For an input like '<script'.repeat(N), the engine encounters N starting < 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²).
Reachability:
1. 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 }}.
2. The filter calls String.prototype.replace with the vulnerable regex directly on the caller-supplied string, with no length cap and no timeout.
3. 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.
This 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 backtrack
Details
Original advisory: https://github.com/advisories/GHSA-r7g9-xpmj-5fcq
Exploitation outlook
EPSS (FIRST.org) estimates each CVE’s probability of exploitation in the next 30 days — here is the CSIRTS.com read on those numbers.
- Low exploitation riskCVE-2026-456170.39% 30-day exploitation probability — currently an unlikely target, but scores change as exploit code circulates. Riskier than 31% of all scored CVEs.
Referenced CVEs
| CVE | CSIRTS overview | External |
|---|---|---|
| CVE-2026-45617 | coverage & exploitation status | NVD · CVE.org |
More from GitHub Security Advisories
- criticalGHSA-g936-7jqj-mwv8: TSDProxy: Internal proxy auth token forwarded to backend services enables management API …2026-07-10
- highGHSA-fpg8-7664-jc5q: melange: Incomplete package integrity verification allows data section substitution2026-07-10
- mediumGHSA-48rx-c7pg-q66r: Excon does not redact additional sensitive/risky headers when following redirects2026-07-10
- highGHSA-h4g2-xfmw-q2c9: Clauster: Non-loopback deployments can serve the dashboard unauthenticated when auth.enab…2026-07-10
- mediumGHSA-rqq5-2gf9-4w4q: Secure Headers: CSP directive injection via sandbox, plugin_types, and report_to when giv…2026-07-10