CVE-2026-44645: LiquidJS renderLimit Bypass DoS Vulnerability

Technical summary

The vulnerability stems from an incomplete implementation of the renderLimit check in LiquidJS's loop handling. The renderLimit option is meant to enforce a per-render timeout by checking elapsed time on each loop iteration; however, this check is only performed when the loop body contains at least one template node. An empty loop body—created using syntax such as {%- for i in (1..N) -%}{%- endfor -%}—allows iteration over the full collection without triggering the per-iteration time check. A template author can construct an arbitrarily large loop range that iterates until hitting the memoryLimit, with no interruption from renderLimit. Testing showed a renderLimit of 50 ms being exceeded by ~45× (2.26 seconds observed) in a single parseAndRenderSync call, scaling linearly with loop count. The unprotected event-loop monopolization directly violates the documented DoS mitigation contract.

Business impact

For organizations using LiquidJS in multi-tenant or user-generated-template scenarios—such as SaaS platforms, dynamic content engines, or template-as-a-service offerings—this vulnerability creates a straightforward denial-of-service vector. A low-privileged template author can submit a single malicious template that stalls Node.js worker threads for seconds at a time, cascading availability degradation across in-flight requests handled by affected workers. The impact is amplified in containerized or resource-constrained deployments where event-loop stalling directly translates to request timeouts and service latency spikes. While confidentiality and integrity are unaffected, availability loss in production environments can damage user trust and SLA compliance.

Affected systems

LiquidJS versions 10.25.7 and earlier are vulnerable. The vulnerability is introduced whenever renderLimit is relied upon as a security control in applications that accept untrusted template input. This includes: Shopify theme builders, GitHub Pages-like static site generators that accept user templates, multi-tenant SaaS platforms using LiquidJS for dynamic rendering, and any application architecture that assumes renderLimit enforces a time-based DoS bound. Applications using LiquidJS but not relying on renderLimit for DoS protection, or those that validate and sanitize templates before execution, have reduced exposure. Version 10.26.0 and later contain the fix.

Exploitability

Exploitability is high for affected deployments because the attack requires only the ability to author or submit a template—a capability that multi-tenant platforms must provide to users by design. No authentication bypass, network tricks, or race conditions are needed. The malicious template is trivially simple (an empty loop over a large range) and is immediately effective on a single render call. However, the vulnerability requires an attacker to have template-authoring privileges; external unauthenticated attack is not possible unless the application publicly accepts template submissions. The vulnerability is not listed on CISA's KEV catalog as of the publication date.

Remediation

Upgrade LiquidJS to version 10.26.0 or later, which correctly implements the per-iteration renderLimit check even for empty loop bodies. For organizations unable to upgrade immediately, implement compensating controls: enforce strict template authoring policies and code review, set aggressive memoryLimit values to reduce the iteration ceiling, use worker thread pool limits to isolate template rendering from critical request handlers, and consider sandboxing template execution in separate processes with independent resource quotas. Monitor event-loop lag and request latency for signs of exploitation.

Patch guidance

Apply the upgrade to LiquidJS 10.26.0 or later in your package.json and run npm update (or equivalent). Verify the version constraint in your build artifacts and test with your application's template workloads to confirm the fix does not introduce performance regressions. If using a monorepo or internal fork, ensure all downstream consumers are updated. For teams with frozen dependency schedules, prioritize this upgrade in the next maintenance window, as the fix is backward compatible.

Detection guidance

Monitor Node.js event-loop lag and worker thread saturation during template rendering operations. Anomalies include sustained high CPU usage from a single parseAndRenderSync call or parseAndRender promise, request queue buildup without clear traffic spikes, and logs showing render operations exceeding the configured renderLimit threshold. Audit template repositories and user submissions for suspicious constructs: empty loops with large iteration ranges, loops using unbounded variables, or nested empty loops. Log and alert on templates that trigger renderLimit timeouts or warnings, as these indicate intentional or accidental resource exhaustion attempts. In multi-tenant systems, correlate render-time anomalies with specific users or accounts.

Why prioritize this

Despite a MEDIUM CVSS score, this vulnerability should be prioritized for rapid remediation in multi-tenant or user-generated-content environments because it directly undermines documented DoS protections and allows low-privileged attackers to reliably degrade availability. The exploit is trivial, requires no special conditions, and scales with attacker intent. Organizations that explicitly marketed or documented renderLimit as a security feature face elevated reputational and SLA risk if not remediated quickly. Single-tenant or tightly controlled template environments can schedule this as a routine update.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects a network-accessible vulnerability with low attack complexity and low privilege requirements, but scoped impact limited to availability (no confidentiality or integrity loss). The score appropriately captures the severity of uncontrolled resource consumption, but context matters: in multi-tenant architectures where template authoring is a core feature and renderLimit is a stated security control, the real-world risk exceeds the base score. Conversely, applications using LiquidJS for static content rendering or as a supplementary feature may face lower practical risk.

Frequently asked questions