CVE-2026-41311

What it actually does

LiquidJS versions prior to 10.25.7 can enter an infinite recursive rendering loop when processing Liquid templates that contain circular references between layout and block constructs. The recursion continuously allocates memory until the Node.js V8 heap is exhausted, commonly ending with a fatal "JavaScript heap out of memory" crash. The vulnerability affects availability only: it does not directly provide code execution, data disclosure, or data modification, but it can terminate the Node.js process handling template rendering.

Why it matters to the business

Applications or services that allow users, contributors, CMS editors, theme authors, or API clients to submit or modify Liquid templates may be remotely crashed with a single malicious template. This can cause website outages, failed page rendering, interrupted publishing workflows, degraded customer experience, and operational load from repeated process restarts. Although this CVE is not currently in CISA KEV and has low EPSS, the network-accessible, unauthenticated, low-complexity denial-of-service characteristics make internet-facing template-rendering services higher priority to patch.

How an attack unfolds

An attacker first identifies an application feature that accepts or stores Liquid templates, such as theme editing, page customization, email/template authoring, CMS content blocks, static-site rendering, or API-driven template submission. The attacker submits a template that creates a circular relationship between Liquid layout and block processing. When the vulnerable LiquidJS renderer processes that template, it repeatedly resolves the same layout/block chain without terminating. Memory usage grows until the Node.js heap is exhausted, after which the runtime aborts with a fatal out-of-memory error. If the affected process is part of a web application, worker pool, job processor, or rendering service, the process crash can interrupt active requests and may recur if the malicious template remains stored and is rendered again after restart.

How to fix it

Upgrade LiquidJS to version 10.25.7 or later wherever it is used. If an immediate upgrade is not possible, reduce exposure by preventing untrusted users from submitting arbitrary Liquid templates, disabling or restricting layout/block features in user-controlled templates where feasible, applying strict template validation to reject circular layout/block patterns, limiting template size and nesting depth, isolating rendering in a separate worker process, and enforcing memory/time limits so a renderer failure does not take down the main application. Ensure package lockfiles and container images are rebuilt so the fixed dependency is actually deployed.

How to confirm the fix worked

Confirm the deployed dependency tree resolves LiquidJS to 10.25.7 or later using package-manager inspection such as npm list liquidjs, yarn why liquidjs, pnpm why liquidjs, software composition analysis, or SBOM review. Verify all runtime artifacts, containers, serverless bundles, and build images include the upgraded package rather than only updating source manifests. Test rendering controls by submitting benign templates with nested layout/block behavior and confirming the renderer terminates safely under configured memory and execution limits. Review application behavior after upgrade to ensure previously stored templates render correctly or are rejected with controlled errors rather than crashing the Node.js process.

Typical attack path

1. Find an exposed feature or API that accepts Liquid template content from untrusted or semi-trusted users.
2. Submit or save a Liquid template containing circular layout/block references.
3. Trigger rendering of the submitted template directly, through preview, publishing, page load, email generation, or a background rendering job.
4. Cause LiquidJS to recurse indefinitely while resolving the layout/block relationship.
5. Exhaust the Node.js heap and crash the process with an out-of-memory fatal error.
6. Repeat requests or rely on a persisted malicious template to cause recurring service disruption until the template is removed or the package is upgraded.

How to detect it

Investigate Node.js application logs, process manager logs, container logs, crash reports, APM traces, and reverse-proxy access logs for sudden memory exhaustion or process restarts associated with template preview, rendering, publishing, theme editing, CMS, or email-generation endpoints. Look for fatal V8 heap errors, repeated restarts of the same renderer process, requests immediately preceding crashes, and recently submitted Liquid templates containing layout and block constructs that reference each other or repeat in a circular pattern. If templates are persisted, review newly created or modified templates around the crash window for suspicious use of {% layout %} and {% block %}. Correlate user accounts, IP addresses, API tokens, user agents, and request IDs that submitted or rendered templates shortly before out-of-memory events. Because public exploit maturity is not currently established and there are no known named threat actors for this CVE, focus detection on behavioral evidence of memory-exhaustion crashes and malicious template content rather than actor-specific infrastructure.

• FATAL ERROR: JavaScript heap out of memory
• JavaScript heap out of memory
• Ineffective mark-compacts near heap limit Allocation failed
• Allocation failed - JavaScript heap out of memory
• Reached heap limit Allocation failed
• node: --max-old-space-size
• SIGABRT
• exit code 134
• OOMKilled
• {% layout
• {% block

What your security team should do

• Prioritize patching internet-facing or multi-tenant applications that allow users to create, edit, import, preview, or publish Liquid templates.
• Upgrade LiquidJS to 10.25.7 or later and redeploy all affected services, workers, containers, and build pipelines.
• Search dependency manifests, lockfiles, SBOMs, and container images for LiquidJS versions earlier than 10.25.7.
• Identify all user-controlled template entry points and restrict arbitrary Liquid template submission where it is not required.
• Add server-side validation or policy controls for Liquid layout/block usage in templates from untrusted sources.
• Run template rendering in isolated workers with CPU, memory, timeout, and restart limits to reduce blast radius from future rendering DoS flaws.
• Review stored templates submitted before remediation and remove suspicious circular layout/block constructs.
• Create monitoring for Node.js out-of-memory crashes and sudden renderer memory growth associated with template rendering routes or jobs.