CVE-2026-69222 exposes a fundamental mismatch between LiquidJS's complexity accounting and actual resource consumption. The join and array_to_sentence_string filters charge based on input array length, but they materialize the entire output string—which can be orders of magnitude larger than the complexity budget suggests. A template that builds a modest array with concat, then joins it, can trigger memory allocation far exceeding what the complexity limit was supposed to enforce. This isn't a simple calculation bug; it's an architectural flaw where the cost model treats reference manipulation (free) and string materialization (charged per-element, not per-output-size) as fundamentally misaligned operations. Two independent filters made the same accounting mistake, suggesting the underlying model was never designed to track reference graph depth or actual string allocation. Version 10.27.2 adds a guard that triggers on V8 string limits, which closes this specific crash vector—but it's a surgical patch on a broken premise. The deeper question is whether the complexity model can ever meaningfully govern string materialization, since computing the cost before materialization is either impossible or defeats the purpose. From a defensive posture: upgrade to 10.27.2 immediately, but treat this as a known gap rather than a closed class. Audit any filter chains that combine array construction with string-emitting filters, even when complexity limits appear configured. The vulnerability is reliably reproducible—an attacker doesn't need precise memory engineering, just enough concatenation to push past V8's string length threshold. This pattern of a cost proxy diverging from actual consumption has recurred across template engines and sandboxing systems; treating the patch as a single fix rather than evidence of a broader architectural problem leaves you exposed to the next variant.
CVE-2026-69222
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedLiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.2, the join filter in src/filters/array.ts computes complexity from array.length and separator length instead of the total string length produced by array.join(sep). The concat filter can cheaply double arrays of references, after which join materializes the referenced content while charging only for element count, allowing a template to exceed a configured memoryLimit by a large factor. The sibling array_to_sentence_string filter in src/filters/string.ts has the same accounting defect, and a crafted template can allocate toward V8's string or process memory limit and crash the process. This issue is fixed in version 10.27.2.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisA single request can consume unbounded CPU, memory, or connections, so a modest amount of malicious traffic exhausts the service. The result is denial of service for everyone else. Remediation is enforcing limits, quotas, and timeouts on what any one request can use.
General guidance for the uncontrolled resource consumption class — the official description and references above are authoritative for this specific CVE. Want a bespoke review and a reviewed fix? Ask our team →
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped10.27.2
- Upgrade liquidjs to version 10.27.2 or later
- If using npm, run: npm install liquidjs@^10.27.2
- If using yarn, run: yarn add liquidjs@^10.27.2
- If using pnpm, run: pnpm add liquidjs@^10.27.2
- After upgrading, verify your application functions correctly with the new version
Generated from the published advisory — verify against the referenced sources before acting.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-69222 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesCVE-2026-69222 exposes a fundamental mismatch between LiquidJS's complexity accounting and actual resource consumption. The join and array_to_sentence_string filters charge based on input array length, but they materialize the entire output string—which can be orders of magnitude larger than the complexity budget suggests. A template that builds a modest array with concat, then joins it, can trigger memory allocation far exceeding what the complexity limit was supposed to enforce. This isn't a simple calculation bug; it's an architectural flaw where the cost model treats reference manipulation (free) and string materialization (charged per-element, not per-output-size) as fundamentally misaligned operations. Two independent filters made the same accounting mistake, suggesting the underlying model was never designed to track reference graph depth or actual string allocation. Version 10.27.2 adds a guard that triggers on V8 string limits, which closes this specific crash vector—but it's a surgical patch on a broken premise. The deeper question is whether the complexity model can ever meaningfully govern string materialization, since computing the cost before materialization is either impossible or defeats the purpose. From a defensive posture: upgrade to 10.27.2 immediately, but treat this as a known gap rather than a closed class. Audit any filter chains that combine array construction with string-emitting filters, even when complexity limits appear configured. The vulnerability is reliably reproducible—an attacker doesn't need precise memory engineering, just enough concatenation to push past V8's string length threshold. This pattern of a cost proxy diverging from actual consumption has recurred across template engines and sandboxing systems; treating the patch as a single fix rather than evidence of a broader architectural problem leaves you exposed to the next variant.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-69222 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data