CVE-2026-44644

LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. Versions 10.25.7 and below are vulnerable to XSS through a flaw in the strip_html filter logic. The strip_html filter is intended to remove HTML tags from a string before rendering, and is widely used as an XSS sanitizer. The implementation uses a regex whose catch-all branch (<.*?>) does not match line terminators, so any HTML tag containing a \n or \r character passes through unmodified. An attacker who can place a newline inside a tag (e.g. <img\nsrc=x\nonerror=alert(1)>) bypasses sanitization entirely, since browsers treat newlines as whitespace within a tag and execute the resulting onerror/onload/etc. handler. Exploitation is possible for applications that both render attacker-controlled strings via {{ x | strip_html }} to defend against HTML injection and do not separately HTML-escape that output (default behavior — outputEscape is unset by default). This issue has been fixed in version 10.26.0.

LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. Versions 10.25.7 and below are vulnerable to XSS through a flaw in the strip_html filter logic. The strip_html filter is intended to remove HTML tags from a string before rendering, and is widely used as an XSS sanitizer. The implementation uses a regex whose catch-all branch (<.*?>) does not match line terminators, so any HTML tag containing a \n or \r character passes through unmodified. An attacker who can place a newline inside a tag (e.g. <img\nsrc=x\nonerror=alert(1)>) bypasses sanitization entirely, since browsers treat newlines as whitespace within a tag and execute the resulting onerror/onload/etc. handler. Exploitation is possible for applications that both render attacker-controlled strings via {{ x | strip_html }} to defend against HTML injection and do not separately HTML-escape that output (default behavior — outputEscape is unset by default). This issue has been fixed in version 10.26.0.

Summary

The strip_html filter in liquidjs is intended to remove HTML tags from a string before rendering, and is widely used as an XSS sanitizer. The implementation uses a regex whose catch-all branch (<.*?>) does not match line terminators, so any HTML tag containing a \n or \r character passes through unmodified. An attacker who can place a newline inside a tag (e.g. <img\nsrc=x\nonerror=alert(1)>) bypasses sanitization entirely, since browsers treat newlines as whitespace within a tag and execute the resulting onerror/onload/etc. handler. This results in stored or reflected XSS in any application that relies on strip_html to neutralize untrusted HTML.

Details

The vulnerable code is in src/filters/html.ts:

// 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 has four alternations:

1. <script[\s\S]*?<\/script> — uses [\s\S], matches across newlines.
2. <style[\s\S]*?<\/style> — uses [\s\S], matches across newlines.
3. <.*?> — uses ., which in JavaScript does not match \n or \r (no s/dotAll flag set).
4. <!--[\s\S]*?--> — uses [\s\S], matches across newlines.

Branch 3 is the catch-all for "any other tag." Because . excludes line terminators, a tag containing a newline does not match any alternative. The literal characters of the tag are passed through to the output.

Browsers, however, parse HTML tag content with whitespace tolerance: per the HTML spec, attribute names and values may be separated by ASCII whitespace, which includes \n and \r. So <img\nsrc=x\nonerror=alert(1)> is parsed as a valid img element with an onerror handler.

liquidjs' default rendering pipeline does not auto-escape filter output (the outputEscape engine option is undefined by default — see src/liquid-options.ts), so the unescaped HTML is delivered verbatim to the consumer's HTML response.

Trust path:

• Application receives untrusted input (e.g. user comment field).
• Developer renders it as {{ comment | strip_html }} to "safely" embed user content as plaintext.
• Attacker submits <img\u000Asrc=x\u000Aonerror=alert(document.cookie)>.
• strip_html returns the input unchanged.
• Output is written into the HTML response with no further escaping.
• Victim's browser executes the attacker's JavaScript in the application's origin.

This is an inconsistency bug: the same regex correctly uses [\s\S] for <script>, <style>, and comment branches, but reverts to . for the catch-all. The other branches' authors clearly knew to handle multi-line content; the catch-all was missed.

PoC

Reproduces against current HEAD (10.25.7) using the published dist/liquid.node.js build:

node -e "
const { Liquid } = require('./dist/liquid.node.js');
const engine = new Liquid();
engine.parseAndRender(
  'Safe output: {{ input | strip_html }}',
  { input: '<img\nsrc=x\nonerror=\"alert(document.cookie)\">' }
).then(r => console.log(JSON.stringify(r)));
"

Verified output:

"Safe output: <img\nsrc=x\nonerror=\"alert(document.cookie)\">"

The <img ... onerror=...> tag is delivered to the output completely unmodified. When this string is placed into an HTML document and parsed by a browser, the onerror handler executes.

Same bypass works with \r (carriage return), \r\n, or any combination of CR/LF inside the tag. It also works with other event-handler vectors (<svg\nonload=alert(1)>, <body\nonload=alert(1)>, <iframe\nsrc="javascript:alert(1)">, etc.) and is not specific to <img>.

For comparison, the same input without a newline is correctly stripped:

node -e "
const { Liquid } = require('./dist/liquid.node.js');
const engine = new Liquid();
engine.parseAndRender(
  'Safe output: {{ input | strip_html }}',
  {…

LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. Versions 10.25.7 and below are vulnerable to XSS through a flaw in the strip_html filter logic. The strip_html filter is intended to remove HTML tags from a string before rendering, and is widely used as an XSS sanitizer. The implementation uses a regex whose catch-all branch (<.*?>) does not match line terminators, so any HTML tag containing a \n or \r character passes through unmodified. An attacker who can place a newline inside a tag (e.g. <img\nsrc=x\nonerror=alert(1)>) bypasses sanitization entirely, since browsers treat newlines as whitespace within a tag and execute the resulting onerror/onload/etc. handler. Exploitation is possible for applications that both render attacker-controlled strings via {{ x | strip_html }} to defend against HTML injection and do not separately HTML-escape that output (default behavior — outputEscape is unset by default). This issue has been fixed in version 10.26.0.

LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. Versions 10.25.7 and below are vulnerable to XSS through a flaw in the strip_html filter logic. The strip_html filter is intended to remove HTML tags from a string before rendering, and is widely used as an XSS sanitizer. The implementation uses a regex whose catch-all branch (<.*?>) does not match line terminators, so any HTML tag containing a \n or \r character passes through unmodified. An attacker who can place a newline inside a tag (e.g. <img\nsrc=x\nonerror=alert(1)>) bypasses sanitization entirely, since browsers treat newlines as whitespace within a tag and execute the resulting onerror/onload/etc. handler. Exploitation is possible for applications that both render attacker-controlled strings via {{ x | strip_html }} to defend against HTML injection and do not separately HTML-escape that output (default behavior — outputEscape is unset by default). This issue has been fixed in version 10.26.0.

Summary

The strip_html filter in liquidjs is intended to remove HTML tags from a string before rendering, and is widely used as an XSS sanitizer. The implementation uses a regex whose catch-all branch (<.*?>) does not match line terminators, so any HTML tag containing a \n or \r character passes through unmodified. An attacker who can place a newline inside a tag (e.g. <img\nsrc=x\nonerror=alert(1)>) bypasses sanitization entirely, since browsers treat newlines as whitespace within a tag and execute the resulting onerror/onload/etc. handler. This results in stored or reflected XSS in any application that relies on strip_html to neutralize untrusted HTML.

Details

The vulnerable code is in src/filters/html.ts:

// 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 has four alternations:

1. <script[\s\S]*?<\/script> — uses [\s\S], matches across newlines.
2. <style[\s\S]*?<\/style> — uses [\s\S], matches across newlines.
3. <.*?> — uses ., which in JavaScript does not match \n or \r (no s/dotAll flag set).
4. <!--[\s\S]*?--> — uses [\s\S], matches across newlines.

Branch 3 is the catch-all for "any other tag." Because . excludes line terminators, a tag containing a newline does not match any alternative. The literal characters of the tag are passed through to the output.

Browsers, however, parse HTML tag content with whitespace tolerance: per the HTML spec, attribute names and values may be separated by ASCII whitespace, which includes \n and \r. So <img\nsrc=x\nonerror=alert(1)> is parsed as a valid img element with an onerror handler.

liquidjs' default rendering pipeline does not auto-escape filter output (the outputEscape engine option is undefined by default — see src/liquid-options.ts), so the unescaped HTML is delivered verbatim to the consumer's HTML response.

Trust path:

• Application receives untrusted input (e.g. user comment field).
• Developer renders it as {{ comment | strip_html }} to "safely" embed user content as plaintext.
• Attacker submits <img\u000Asrc=x\u000Aonerror=alert(document.cookie)>.
• strip_html returns the input unchanged.
• Output is written into the HTML response with no further escaping.
• Victim's browser executes the attacker's JavaScript in the application's origin.

This is an inconsistency bug: the same regex correctly uses [\s\S] for <script>, <style>, and comment branches, but reverts to . for the catch-all. The other branches' authors clearly knew to handle multi-line content; the catch-all was missed.

PoC

Reproduces against current HEAD (10.25.7) using the published dist/liquid.node.js build:

node -e "
const { Liquid } = require('./dist/liquid.node.js');
const engine = new Liquid();
engine.parseAndRender(
  'Safe output: {{ input | strip_html }}',
  { input: '<img\nsrc=x\nonerror=\"alert(document.cookie)\">' }
).then(r => console.log(JSON.stringify(r)));
"

Verified output:

"Safe output: <img\nsrc=x\nonerror=\"alert(document.cookie)\">"

The <img ... onerror=...> tag is delivered to the output completely unmodified. When this string is placed into an HTML document and parsed by a browser, the onerror handler executes.

Same bypass works with \r (carriage return), \r\n, or any combination of CR/LF inside the tag. It also works with other event-handler vectors (<svg\nonload=alert(1)>, <body\nonload=alert(1)>, <iframe\nsrc="javascript:alert(1)">, etc.) and is not specific to <img>.

For comparison, the same input without a newline is correctly stripped:

node -e "
const { Liquid } = require('./dist/liquid.node.js');
const engine = new Liquid();
engine.parseAndRender(
  'Safe output: {{ input | strip_html }}',
  {…