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.

Affected: npm: liquidjs

# `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`:

```ts 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…