LiquidJS Has Memory Limit Bypass via Quadratic Amplification in `replace` Filter

The core of the vulnerability lies in the replace filter's inaccurate memory usage calculation. When the memoryLimit option is enabled, the filter incorrectly estimates the memory required for string replacement. An attacker who controls the template content can craft a pattern and replacement string that, when processed, results in a significantly larger output string than initially anticipated. This amplification can be as high as 2,500x, allowing an attacker to bypass the intended memory limit and trigger an out-of-memory error, effectively causing a denial of service. This is particularly concerning in environments where LiquidJS is used to render dynamic content, as malicious templates could be injected to disrupt service.

Applications and services utilizing LiquidJS versions prior to 10.25.3 are at risk. This includes Node.js applications that rely on LiquidJS for templating, particularly those handling user-supplied content or external data within templates. Shared hosting environments where multiple users can influence template content are also at increased risk.

• nodejs: Monitor LiquidJS process memory usage. Sudden spikes in memory consumption, especially during template rendering, could indicate exploitation.

ps aux | grep liquidjs | awk '{print $6}' | sort -n

• nodejs: Check for unusual template content patterns. Look for extremely long patterns or replacement strings in template files or input data.

grep -r 'very_long_pattern_here' /path/to/templates

• generic web: Examine web server access logs for requests containing unusually large template parameters. This may indicate an attempt to trigger the vulnerability.

1. 2026-04-08Disclosure

   disclosure

1. Reserviert2026-03-25
2. Veröffentlicht2026-04-08
3. Geändert2026-04-09
4. EPSS aktualisiert2026-04-16

The primary mitigation for CVE-2026-34166 is to upgrade LiquidJS to version 10.25.3 or later, which includes the corrected memory usage calculation. If upgrading is not immediately feasible, consider implementing stricter input validation on template content to prevent excessively long patterns or replacement strings. While a direct WAF rule is unlikely to be effective due to the nature of the vulnerability, limiting the overall size of template inputs can provide a degree of protection. After upgrading, confirm the fix by testing template rendering with large strings and verifying that the memory limit is enforced as expected.