CVE-2026-33285

What it actually does

LiquidJS prior to 10.25.1 incorrectly enforces its memoryLimit protection when processing reverse range expressions such as `(100000000..1)`. A crafted template can cause the engine to allocate far more memory than intended, and when combined with string-flattening filters such as `replace`, can trigger a V8 fatal out-of-memory error. Because this terminates the Node.js process, the primary technical impact is unauthenticated remote denial of service in applications that render attacker-controlled Liquid templates or template fragments.

Why it matters to the business

An exposed application that allows users to submit or influence LiquidJS templates can be crashed by a single malicious request, causing service outages, failed transactions, degraded customer experience, and possible cascading failures if the Node.js process is not isolated or automatically restarted. The vulnerability is not known to be in CISA KEV and has low EPSS at this time, but the exploit condition is simple once an attacker can reach a template-rendering path, so internet-facing uses of LiquidJS should be prioritized for remediation.

How an attack unfolds

An attacker first identifies an application feature that renders user-supplied or user-influenced LiquidJS content, such as CMS templates, page builders, email templates, markdown/front-matter rendering, preview endpoints, or theme customization. The attacker submits a crafted Liquid expression containing a very large reverse range, for example `(100000000..1)`, which bypasses LiquidJS's intended memory limit checks in vulnerable versions. They then combine that expression with an operation that forces string materialization or flattening, such as the `replace` filter. During rendering, LiquidJS and the underlying V8 JavaScript engine attempt to allocate excessive memory. This can produce a fatal V8 out-of-memory condition and terminate the Node.js process, resulting in denial of service. If the process manager restarts the service, repeated requests can keep the application unstable or unavailable.

How to fix it

Upgrade LiquidJS to version 10.25.1 or later wherever the package is used. Because no per-package fixed version list was provided beyond the advisory text, treat 10.25.1 as the minimum safe upstream version and verify all direct and transitive dependency resolutions. Rebuild and redeploy affected Node.js services after updating lockfiles. If immediate upgrade is not possible, restrict or disable rendering of untrusted Liquid templates, block or sanitize range expressions from untrusted input, enforce strict request size and rendering timeouts, isolate template rendering in a worker process with memory limits, and ensure process supervision can restart crashed workers without taking down the whole service. These mitigations reduce exposure but should not replace upgrading.

How to confirm the fix worked

Confirm that deployed applications resolve LiquidJS to 10.25.1 or later using package manager tooling such as `npm ls liquidjs`, `yarn why liquidjs`, `pnpm why liquidjs`, or software composition analysis. Review lockfiles and container images to ensure no vulnerable copy remains. In a non-production environment, attempt to render a known reverse-range stress template using the same rendering path and confirm the process does not exceed configured memory limits or crash. Validate that untrusted template submission points are authenticated, authorized, rate-limited, and subject to rendering timeouts. Confirm monitoring shows no new Node.js out-of-memory crashes after deployment.

Typical attack path

1. Locate an application endpoint or workflow that renders LiquidJS templates or accepts user-controlled Liquid syntax.
2. Submit a probe template containing range syntax to confirm LiquidJS evaluation behavior.
3. Craft a payload using a very large reverse range expression such as `(100000000..1)`.
4. Add a string-flattening operation, commonly a filter such as `replace`, to force excessive memory allocation during rendering.
5. Send the malicious template in a single HTTP request to the vulnerable rendering endpoint.
6. Cause the Node.js/V8 process to exhaust memory and crash, producing application denial of service.
7. Optionally repeat requests after service restart to sustain the outage.

How to detect it

Investigate web access logs, application logs, reverse proxy logs, API gateway logs, and crash telemetry for requests containing Liquid syntax with large reverse ranges, especially patterns like `(100000000..1)` combined with filters such as `replace`. Review Node.js process manager logs, container runtime events, system logs, and APM traces for abrupt process exits, restarts, or V8 out-of-memory messages occurring immediately after template rendering requests. Look for repeated 500/502/503 responses, pod or container restarts, `OOMKilled` events, and fatal JavaScript heap errors. If request bodies are logged or retained in WAF/API telemetry, search for range operators `..` inside parentheses with descending numeric values and unusually large integers. There are no known named threat actors or KEV exploitation reports in the provided data, so focus detection on exploit behavior and denial-of-service artifacts rather than actor-specific infrastructure.

• (100000000..1)
• ..1) | replace
• | replace
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• FatalProcessOutOfMemory
• JavaScript heap out of memory
• Allocation failed - process out of memory
• OOMKilled
• v8::internal::V8::FatalProcessOutOfMemory
• liquidjs
• LiquidJS

What your security team should do

• Inventory applications, services, build tools, CMS features, and preview/rendering endpoints that use LiquidJS, especially those processing user-controlled templates.
• Prioritize internet-facing or multi-tenant template rendering services for upgrade to LiquidJS 10.25.1 or later.
• Regenerate and review package lockfiles, then redeploy affected services and container images.
• Add temporary WAF or application-layer detection for suspicious Liquid reverse ranges and high-magnitude range expressions where practical.
• Place untrusted template rendering behind resource-constrained worker isolation, memory limits, execution timeouts, and rate limits.
• Monitor Node.js services for V8 fatal out-of-memory crashes and correlate events with recent HTTP requests containing Liquid syntax.
• Create regression tests for large forward and reverse range expressions to prevent reintroduction of unsafe template behavior.