CVE-2026-45357

What it actually does

The vulnerability exists in the `date` filter's `strftime` implementation within LiquidJS. When parsing a format string, it incorrectly handles large width specifiers (e.g., `%999999d`). The extracted width is passed unchecked to padding functions (`pad()`/`padStart()`), which then perform unbounded string concatenation in a loop. This bypasses the library's built-in `memoryLimit` and `renderLimit` denial-of-service protections, allowing a small template to trigger massive memory allocation and CPU consumption, leading to a process crash.

Why it matters to the business

An unauthenticated attacker can cause a denial of service (DoS) against applications using the vulnerable LiquidJS library. By submitting a specially crafted template, an attacker can trigger excessive resource consumption on the server, leading to application slowdowns, unresponsiveness, or crashes. This impacts service availability for all users, potentially causing operational disruption, reputational damage, and financial loss if the affected application is business-critical.

How an attack unfolds

An attacker identifies an application that renders user-supplied input using a vulnerable version of LiquidJS. The attacker crafts a simple string containing a LiquidJS `date` filter with an extremely large width specifier, such as `{{ 'now' | date: '%5000000d' }}`. This string is submitted to the application through any available input vector (e.g., a form field, URL parameter, or API call). When the server-side template engine processes this malicious string, the `strftime` function's flaw is triggered. The engine enters a resource-intensive loop, attempting to pad a string millions of times. This bypasses documented safety limits, rapidly consuming all available CPU and memory, and ultimately causing the application process to hang or crash from an Out-of-Memory (OOM) error.

How to fix it

The definitive fix is to upgrade the LiquidJS library to the patched version, 10.26.0, or any subsequent version. Update your project's `package.json` to specify the fixed version and run your package manager's install command (e.g., `npm install` or `yarn install`) to apply the update. If an immediate upgrade is impossible, consider implementing strict input validation as a temporary mitigation to sanitize or reject user input containing LiquidJS `date` filters with large numerical format specifiers before it reaches the rendering engine.

How to confirm the fix worked

To confirm remediation, inspect your project's dependency lock file (`package-lock.json`, `yarn.lock`) to ensure that the resolved version of LiquidJS is 10.26.0 or higher. To validate the fix, you can create a controlled test case in a non-production environment. Attempt to render a template containing the malicious payload (e.g., `{{ 'now' | date: '%1000000d' }}`) and monitor the application's resource usage. A patched system will handle the input gracefully without significant CPU or memory spikes, while a vulnerable system will exhibit resource exhaustion.

Typical attack path

1. Attacker identifies a target application using a vulnerable version of LiquidJS (<=10.25.7).
2. Attacker locates an input vector where user-provided data is processed by the LiquidJS template engine.
3. Attacker submits a malicious payload containing a `date` filter with a very large width specifier.
4. The server attempts to render the template, triggering the unbounded string concatenation flaw.
5. The server process experiences extreme CPU and memory consumption, leading to a denial of service.

How to detect it

Monitor application logs, web server access logs, and WAF logs for incoming requests containing strings that match the exploitation pattern. Specifically, look for LiquidJS templates that use the `date` filter with a large numerical width specifier (e.g., `... | date: '%99999d' ...`). Correlate these findings with server performance monitoring. A sudden, sharp increase in CPU utilization and memory allocation for the Node.js process hosting the application, potentially culminating in an Out-of-Memory (OOM) error or process crash, is a strong indicator of exploitation.

• | date: '%[0-9]{4,}
• | date: '%5000000d'
• | date: '%9999999d'

What your security team should do

• Immediately prioritize upgrading all applications using LiquidJS to version 10.26.0 or newer.
• Use software composition analysis (SCA) tools to scan your codebase and identify all instances of the vulnerable LiquidJS dependency.
• Monitor application performance metrics for anomalous spikes in CPU and memory usage, as this could indicate an active exploitation attempt.
• If patching is delayed, implement web application firewall (WAF) rules or input validation logic to block requests containing patterns like `| date: '%[0-9]{4,}`.