GHSA-G357-X5C3-C72P

Vulnerability from github – Published: 2026-07-24 14:05 – Updated: 2026-07-24 14:05

Summary

LiquidJS: `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce

Details

`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 }} allocates an O(N) clone outside the budget.
Realistic attack surface: when a server passes an attacker-influenced large array to the template context (search results, paginated lists, batch-export pages) and the template uses | pop anywhere on it, a single render can allocate hundreds of MB of array slots that the operator believed memoryLimit had ruled out.
Concurrent amplification: N parallel requests each allocate their own unguarded clone — the practical ceiling is the Node process heap, after which the host runs oom-kill. This is the same outcome the renderLimit-empty-body advisories (GHSA-8xx9-69p8-7jp3 / GHSA-2546-xv4c-mc8g) prevented for CPU; this report prevents it for memory.

Severity is configuration-dependent (requires memoryLimit to be set, plus a template that uses pop, plus attacker-influenced array length). For deployments that rely on memoryLimit as a DoS guard, this is a real bypass of that guard.

Workaround for users

Until a fix lands, deployments relying on memoryLimit should either:

Avoid | pop in templates whose inputs include untrusted-length arrays. Use | slice: 0, arr.size | minus: 1 or equivalent guarded alternatives.
Register a wrapping pop filter that does the accounting:

js liquid.registerFilter('pop', function (v) { const arr = Array.from(v ?? []); this.context.memoryLimit.use(arr.length); arr.pop(); return arr; });

Suggested fix

One-line addition mirroring shift:

export function pop<T> (this: FilterImpl, v: T[]): T[] {
  const array = toArray(v)
  this.context.memoryLimit.use(array.length)   // ← add this line, and add `this: FilterImpl`
  const clone = [...array]
  clone.pop()
  return clone
}

No API or behavior change for callers within budget; rejects out-of-budget calls with the standard memory alloc limit exceeded exception the sibling filters already throw.

Severity

N/A (UNKNOWN)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.27.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "liquidjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.27.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55575"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T14:05:20Z",
    "nvd_published_at": "2026-07-08T20:16:53Z",
    "severity": "HIGH"
  },
  "details": "# `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce\n\n**CWE**: CWE-770 (Allocation of Resources Without Limits or Throttling) \u2014 sibling class of GHSA-8xx9-69p8-7jp3 and GHSA-2546-xv4c-mc8g, applied to `memoryLimit` instead of `renderLimit`\n\n## Summary\n\nThe `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.\n\n## Affected\n\n- liquidjs \u2265 all versions that ship the current `pop` filter implementation (verified `10.27.0`, HEAD `a8fd734b5`)\n- 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.)\n\n## Vulnerability details\n\n### Code\n\n`src/filters/array.ts:91-95`:\n\n```ts\nexport function pop\u003cT\u003e (v: T[]): T[] {\n  const clone = [...toArray(v)]   // O(N) allocation \u2014 not charged to memoryLimit\n  clone.pop()\n  return clone\n}\n```\n\nNote: the function signature does not even declare `this: FilterImpl`, so it has no typed access to `this.context.memoryLimit` at the type level \u2014 a visual tell that the author skipped the limit-accounting boilerplate the surrounding filters use.\n\nCompare with `shift` (`src/filters/array.ts:97-103`), which is functionally identical except for the array-end operated on:\n\n```ts\nexport function shift\u003cT\u003e (this: FilterImpl, v: T[]): T[] {\n  const array = toArray(v)\n  this.context.memoryLimit.use(array.length)   // \u2190 guard present\n  const clone = [...array]\n  clone.shift()\n  return clone\n}\n```\n\nAnd `unshift`, `compact`, `concat`, `reverse`, `sample`, `slice`, `map`, `sortBy`, `where`, `group_by`, `uniq` \u2014 all of which also charge `memoryLimit.use(array.length)` (or `lhs.length + rhs.length` etc.) before allocating their working buffer.\n\nThe asymmetry confirms `pop` is an accidental omission, not by design.\n\n### Why the bypass matters\n\n`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 \u2014 the allocation proceeds, and the only ceiling is the Node process\u0027s heap.\n\n## Proof of concept\n\n```js\nconst { Liquid } = require(\u0027liquidjs\u0027);\n\nconst l    = new Liquid({ memoryLimit: 100 });        // 100-unit budget\nconst huge = Array(5_000_000).fill(\u0027x\u0027);              // 5M-element context array\n\n(async () =\u003e {\n  try { await l.parseAndRender(\u0027{{ a | shift | size }}\u0027, { a: huge }); }\n  catch (e) { console.log(\u0027shift:   \u0027 + e.message); }      // expected: memory alloc limit exceeded\n\n  try { await l.parseAndRender(\u0027{{ a | unshift: 0 | size }}\u0027, { a: huge }); }\n  catch (e) { console.log(\u0027unshift: \u0027 + e.message); }      // expected: memory alloc limit exceeded\n\n  const out = await l.parseAndRender(\u0027{{ a | pop | size }}\u0027, { a: huge });\n  console.log(\u0027pop:     OK, size=\u0027 + out);                  // size=4999999 \u2014 allocation succeeded\n})();\n```\n\nObserved (against `dist/liquid.node.js` at `a8fd734b5`):\n\n```\nshift:   memory alloc limit exceeded, line:1, col:1\nunshift: memory alloc limit exceeded, line:1, col:1\npop:     OK, size=4999999\n```\n\n## Impact\n\n- **`memoryLimit` does not bound `pop` allocations.** Any template that can reach `{{ \u003cuntrusted-sized array\u003e | pop }}` allocates an O(N) clone outside the budget.\n- **Realistic attack surface**: when a server passes an attacker-influenced large array to the template context (search results, paginated lists, batch-export pages) and the template uses `| pop` anywhere on it, a single render can allocate hundreds of MB of array slots that the operator believed `memoryLimit` had ruled out.\n- **Concurrent amplification**: N parallel requests each allocate their own unguarded clone \u2014 the practical ceiling is the Node process heap, after which the host runs `oom-kill`. This is the same outcome the renderLimit-empty-body advisories (GHSA-8xx9-69p8-7jp3 / GHSA-2546-xv4c-mc8g) prevented for CPU; this report prevents it for memory.\n\nSeverity is configuration-dependent (requires `memoryLimit` to be set, plus a template that uses `pop`, plus attacker-influenced array length). For deployments that rely on `memoryLimit` as a DoS guard, this is a real bypass of that guard.\n\n## Workaround for users\n\nUntil a fix lands, deployments relying on `memoryLimit` should either:\n\n- Avoid `| pop` in templates whose inputs include untrusted-length arrays. Use `| slice: 0, arr.size | minus: 1` or equivalent guarded alternatives.\n- Register a wrapping `pop` filter that does the accounting:\n\n  ```js\n  liquid.registerFilter(\u0027pop\u0027, function (v) {\n    const arr = Array.from(v ?? []);\n    this.context.memoryLimit.use(arr.length);\n    arr.pop();\n    return arr;\n  });\n  ```\n\n## Suggested fix\n\nOne-line addition mirroring `shift`:\n\n```ts\nexport function pop\u003cT\u003e (this: FilterImpl, v: T[]): T[] {\n  const array = toArray(v)\n  this.context.memoryLimit.use(array.length)   // \u2190 add this line, and add `this: FilterImpl`\n  const clone = [...array]\n  clone.pop()\n  return clone\n}\n```\n\nNo API or behavior change for callers within budget; rejects out-of-budget calls with the standard `memory alloc limit exceeded` exception the sibling filters already throw.",
  "id": "GHSA-g357-x5c3-c72p",
  "modified": "2026-07-24T14:05:20Z",
  "published": "2026-07-24T14:05:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-g357-x5c3-c72p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55575"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/pull/907"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/commit/8a0c74a7fcb1671aa1dcb71ec82ba0602dc90d04"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/harttle/liquidjs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/releases/tag/v10.27.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/",
      "type": "CVSS_V4"
    }
  ],
  "summary": "LiquidJS: `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce"
}

CVE-2026-55575 (GCVE-0-2026-55575)

Vulnerability from cvelistv5 – Published: 2026-07-08 19:32 – Updated: 2026-07-09 14:00

Title

LiquidJS: `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce

Summary

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.

Severity

8.2 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

SSVC

Exploitation: poc Automatable: yes Technical Impact: total

CISA Coordinator (v2.0.3)

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitHub_M

References

4 references

URL	Tags
https://github.com/harttle/liquidjs/security/advi…	x_refsource_CONFIRM
https://github.com/harttle/liquidjs/pull/907	x_refsource_MISC
https://github.com/harttle/liquidjs/commit/8a0c74…	x_refsource_MISC
https://github.com/harttle/liquidjs/releases/tag/…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
harttle	liquidjs	Affected: < 10.27.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-55575",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-09T13:59:36.356874Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-09T14:00:04.585Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-g357-x5c3-c72p"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "liquidjs",
          "vendor": "harttle",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 10.27.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-08T19:32:01.216Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/harttle/liquidjs/security/advisories/GHSA-g357-x5c3-c72p",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-g357-x5c3-c72p"
        },
        {
          "name": "https://github.com/harttle/liquidjs/pull/907",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/harttle/liquidjs/pull/907"
        },
        {
          "name": "https://github.com/harttle/liquidjs/commit/8a0c74a7fcb1671aa1dcb71ec82ba0602dc90d04",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/harttle/liquidjs/commit/8a0c74a7fcb1671aa1dcb71ec82ba0602dc90d04"
        },
        {
          "name": "https://github.com/harttle/liquidjs/releases/tag/v10.27.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/harttle/liquidjs/releases/tag/v10.27.1"
        }
      ],
      "source": {
        "advisory": "GHSA-g357-x5c3-c72p",
        "discovery": "UNKNOWN"
      },
      "title": "LiquidJS: `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-55575",
    "datePublished": "2026-07-08T19:32:01.216Z",
    "dateReserved": "2026-06-16T23:11:20.214Z",
    "dateUpdated": "2026-07-09T14:00:04.585Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

GHSA-G357-X5C3-C72P

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

Summary

Affected

Vulnerability details

Code

Why the bypass matters

Proof of concept

Impact

Workaround for users

Suggested fix

CVE-2026-55575 (GCVE-0-2026-55575)

Tags

Sightings

Nomenclature

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