Vulnerability-Lookup

GHSA-8XX9-69P8-7JP3

Vulnerability from github – Published: 2026-05-27 00:11 – Updated: 2026-05-27 00:11

Summary

LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body

Details

Summary

The renderLimit option — documented in docs/source/tutorials/dos.md as the mechanism that "mitigates this by limiting the time consumed by each render() call" — can be fully bypassed by a {% for %} (or {% tablerow %}) tag whose body is empty. The per-iteration time check is reached only when the body contains at least one template node, so a template like {%- for i in (1..N) -%}{%- endfor -%} iterates the full collection without ever consulting renderLimit. With a configured renderLimit of 50 ms, a single parseAndRenderSync call has been observed to consume 2.26 seconds (~45× over the limit) and scales linearly with N up to memoryLimit, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration.

Details

Render.renderTemplates is the single point at which renderLimit is consulted:

// src/render/render.ts
14:  public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator<any> {
15:    if (!emitter) {
16:      emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()
17:    }
18:    const errors = []
19:    for (const tpl of templates) {
20:      ctx.renderLimit.check(getPerformance().now())
21:      try {
22:        const html = yield tpl.render(ctx, emitter)
...
32:    }

The check at line 20 lives inside the for (const tpl of templates) body. When templates.length === 0, the loop body never executes, so the limiter is never consulted on that invocation.

The for tag re-enters renderTemplates once per collection item with no independent time check:

// src/tags/for.ts
70:    for (const item of collection) {
71:      scope[this.variable] = item
72:      ctx.continueCalled = ctx.breakCalled = false
73:      yield r.renderTemplates(this.templates, ctx, emitter)
74:      if (ctx.breakCalled) break
75:      scope.forloop.next()
76:    }

When {%- for i in (1..N) -%}{%- endfor -%} is parsed, this.templates is []. Each of the N calls to r.renderTemplates(this.templates, ctx, emitter) therefore performs zero renderLimit.check() calls and zero template work — it just spins the JS-level for loop and the generator boilerplate. With N = 30_000_000 this still costs ~2.26 s of CPU, and N = 100_000_000 costs ~9.6 s, fully bypassing whatever wall-clock budget the integrator configured.

The range expression itself is bounded only by memoryLimit:

// src/render/expression.ts:67-72
function * evalRangeToken (token: RangeToken, ctx: Context) {
  const low: number = yield evalToken(token.lhs, ctx)
  const high: number = yield evalToken(token.rhs, ctx)
  ctx.memoryLimit.use(high - low + 1)
  return range(+low, +high + 1)
}

So the maximum bypass is governed by the (separate) memoryLimit, not by renderLimit. Integrators following the docs/source/tutorials/dos.md guidance — which positions renderLimit as the time-based defense — get no time-based defense at all on this code path.

PoC

Reproduced against liquidjs@10.25.7 (HEAD 34877950):

# Empty for-body bypasses renderLimit (50 ms) and runs for ~2.26 s:
$ node -e "const { Liquid } = require('liquidjs');
  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });
  const t = Date.now();
  engine.parseAndRenderSync('{%- for i in (1..30000000) -%}{%- endfor -%}', {});
  console.log('Took', Date.now()-t, 'ms');"
Took 2255 ms

# Same template with a single-character body is correctly bounded:
$ node -e "const { Liquid } = require('liquidjs');
  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });
  try { engine.parseAndRenderSync('{%- for i in (1..30000000) -%}.{%- endfor -%}', {}); }
  catch(e) { console.log('correctly threw:', e.message); }"
correctly threw: template render limit exceeded, line:1, col:1

Scaling N: - N = 30_000_000 → 2255 ms (≈ 45× over the 50 ms limit) - N = 100_000_000 → 9581 ms (≈ 191× over the 50 ms limit)

Time grows linearly with N, capped only by memoryLimit (default Infinity, so the only cap by default is process memory).

Impact

Any liquidjs integrator who follows the upstream DoS guidance and sets a finite renderLimit to bound per-render CPU — typical for SaaS / multi-tenant environments where end users author templates (themes, email templates, snippets) — does not get the bound they configured. A single template submission can keep an event-loop thread busy for seconds, which on a Node.js server is sufficient to stall all in-flight requests on that worker. With a large enough range and a permissive memoryLimit, the wedge time is attacker-controlled. No data is exposed and no integrity is harmed; impact is availability only.

Recommended Fix

Move the renderLimit check to a location that runs unconditionally per renderTemplates invocation, so a zero-template body still triggers it; alternatively (or additionally) have iteration tags that invoke renderTemplates per element check the limiter themselves once per iteration.

// src/render/render.ts — check at function entry, before the templates loop
public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator<any> {
  if (!emitter) {
    emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()
  }
  ctx.renderLimit.check(getPerformance().now())   // <-- runs even when templates is empty
  const errors = []
  for (const tpl of templates) {
    ctx.renderLimit.check(getPerformance().now())
    ...
  }
  ...
}

And/or, defensively, in the iteration tags themselves so the guard cost is paid once per element rather than only at re-entry:

// src/tags/for.ts (around line 70)
for (const item of collection) {
  ctx.renderLimit.check(getPerformance().now())   // <-- per-iteration time check
  scope[this.variable] = item
  ctx.continueCalled = ctx.breakCalled = false
  yield r.renderTemplates(this.templates, ctx, emitter)
  if (ctx.breakCalled) break
  scope.forloop.next()
}

// src/tags/tablerow.ts (around line 54) — analogous addition
for (let idx = 0; idx < collection.length; idx++, tablerowloop.next()) {
  ctx.renderLimit.check(getPerformance().now())
  ...
}

The same hardening should be applied anywhere a tag drives an attacker-influenced loop count over a (potentially empty) templates array.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "liquidjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "10.25.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T00:11:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `renderLimit` option \u2014 documented in `docs/source/tutorials/dos.md` as the mechanism that \"mitigates this by limiting the time consumed by each render() call\" \u2014 can be fully bypassed by a `{% for %}` (or `{% tablerow %}`) tag whose body is empty. The per-iteration time check is reached only when the body contains at least one template node, so a template like `{%- for i in (1..N) -%}{%- endfor -%}` iterates the full collection without ever consulting `renderLimit`. With a configured `renderLimit` of 50 ms, a single `parseAndRenderSync` call has been observed to consume **2.26 seconds** (~45\u00d7 over the limit) and scales linearly with `N` up to `memoryLimit`, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration.\n\n## Details\n\n`Render.renderTemplates` is the single point at which `renderLimit` is consulted:\n\n```ts\n// src/render/render.ts\n14:  public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator\u003cany\u003e {\n15:    if (!emitter) {\n16:      emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()\n17:    }\n18:    const errors = []\n19:    for (const tpl of templates) {\n20:      ctx.renderLimit.check(getPerformance().now())\n21:      try {\n22:        const html = yield tpl.render(ctx, emitter)\n...\n32:    }\n```\n\nThe check at line 20 lives **inside** the `for (const tpl of templates)` body. When `templates.length === 0`, the loop body never executes, so the limiter is never consulted on that invocation.\n\nThe `for` tag re-enters `renderTemplates` once per collection item with no independent time check:\n\n```ts\n// src/tags/for.ts\n70:    for (const item of collection) {\n71:      scope[this.variable] = item\n72:      ctx.continueCalled = ctx.breakCalled = false\n73:      yield r.renderTemplates(this.templates, ctx, emitter)\n74:      if (ctx.breakCalled) break\n75:      scope.forloop.next()\n76:    }\n```\n\nWhen `{%- for i in (1..N) -%}{%- endfor -%}` is parsed, `this.templates` is `[]`. Each of the `N` calls to `r.renderTemplates(this.templates, ctx, emitter)` therefore performs zero `renderLimit.check()` calls and zero template work \u2014 it just spins the JS-level `for` loop and the generator boilerplate. With `N = 30_000_000` this still costs ~2.26 s of CPU, and `N = 100_000_000` costs ~9.6 s, fully bypassing whatever wall-clock budget the integrator configured.\n\nThe range expression itself is bounded only by `memoryLimit`:\n\n```ts\n// src/render/expression.ts:67-72\nfunction * evalRangeToken (token: RangeToken, ctx: Context) {\n  const low: number = yield evalToken(token.lhs, ctx)\n  const high: number = yield evalToken(token.rhs, ctx)\n  ctx.memoryLimit.use(high - low + 1)\n  return range(+low, +high + 1)\n}\n```\n\nSo the maximum bypass is governed by the (separate) `memoryLimit`, not by `renderLimit`. Integrators following the `docs/source/tutorials/dos.md` guidance \u2014 which positions `renderLimit` as the time-based defense \u2014 get no time-based defense at all on this code path.\n\n## PoC\n\nReproduced against `liquidjs@10.25.7` (HEAD `34877950`):\n\n```bash\n# Empty for-body bypasses renderLimit (50 ms) and runs for ~2.26 s:\n$ node -e \"const { Liquid } = require(\u0027liquidjs\u0027);\n  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });\n  const t = Date.now();\n  engine.parseAndRenderSync(\u0027{%- for i in (1..30000000) -%}{%- endfor -%}\u0027, {});\n  console.log(\u0027Took\u0027, Date.now()-t, \u0027ms\u0027);\"\nTook 2255 ms\n\n# Same template with a single-character body is correctly bounded:\n$ node -e \"const { Liquid } = require(\u0027liquidjs\u0027);\n  const engine = new Liquid({ memoryLimit: 1e9, renderLimit: 50 });\n  try { engine.parseAndRenderSync(\u0027{%- for i in (1..30000000) -%}.{%- endfor -%}\u0027, {}); }\n  catch(e) { console.log(\u0027correctly threw:\u0027, e.message); }\"\ncorrectly threw: template render limit exceeded, line:1, col:1\n```\n\nScaling `N`:\n- `N = 30_000_000` \u2192 2255 ms (\u2248 45\u00d7 over the 50 ms limit)\n- `N = 100_000_000` \u2192 9581 ms (\u2248 191\u00d7 over the 50 ms limit)\n\nTime grows linearly with `N`, capped only by `memoryLimit` (default `Infinity`, so the only cap by default is process memory).\n\n## Impact\n\nAny liquidjs integrator who follows the upstream DoS guidance and sets a finite `renderLimit` to bound per-render CPU \u2014 typical for SaaS / multi-tenant environments where end users author templates (themes, email templates, snippets) \u2014 does not get the bound they configured. A single template submission can keep an event-loop thread busy for seconds, which on a Node.js server is sufficient to stall all in-flight requests on that worker. With a large enough range and a permissive `memoryLimit`, the wedge time is attacker-controlled. No data is exposed and no integrity is harmed; impact is availability only.\n\n## Recommended Fix\n\nMove the `renderLimit` check to a location that runs unconditionally per `renderTemplates` invocation, so a zero-template body still triggers it; alternatively (or additionally) have iteration tags that invoke `renderTemplates` per element check the limiter themselves once per iteration.\n\n```ts\n// src/render/render.ts \u2014 check at function entry, before the templates loop\npublic * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator\u003cany\u003e {\n  if (!emitter) {\n    emitter = ctx.opts.keepOutputType ? new KeepingTypeEmitter() : new SimpleEmitter()\n  }\n  ctx.renderLimit.check(getPerformance().now())   // \u003c-- runs even when templates is empty\n  const errors = []\n  for (const tpl of templates) {\n    ctx.renderLimit.check(getPerformance().now())\n    ...\n  }\n  ...\n}\n```\n\nAnd/or, defensively, in the iteration tags themselves so the guard cost is paid once per element rather than only at re-entry:\n\n```ts\n// src/tags/for.ts (around line 70)\nfor (const item of collection) {\n  ctx.renderLimit.check(getPerformance().now())   // \u003c-- per-iteration time check\n  scope[this.variable] = item\n  ctx.continueCalled = ctx.breakCalled = false\n  yield r.renderTemplates(this.templates, ctx, emitter)\n  if (ctx.breakCalled) break\n  scope.forloop.next()\n}\n\n// src/tags/tablerow.ts (around line 54) \u2014 analogous addition\nfor (let idx = 0; idx \u003c collection.length; idx++, tablerowloop.next()) {\n  ctx.renderLimit.check(getPerformance().now())\n  ...\n}\n```\n\nThe same hardening should be applied anywhere a tag drives an attacker-influenced loop count over a (potentially empty) `templates` array.",
  "id": "GHSA-8xx9-69p8-7jp3",
  "modified": "2026-05-27T00:11:46Z",
  "published": "2026-05-27T00:11:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/harttle/liquidjs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body"
}

CVE-2026-44645 (GCVE-0-2026-44645)

Vulnerability from cvelistv5 – Published: 2026-06-17 22:08 – Updated: 2026-06-18 19:05

Title

LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body

Summary

LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the renderLimit option can be fully bypassed by a {% for %} (or {% tablerow %}) tag whose body is empty. The renderLimit option is documented in docs/source/tutorials/dos.md as the mechanism that "mitigates this by limiting the time consumed by each render() call." The per-iteration time check is reached only when the body contains at least one template node, so a template such as {%- for i in (1..N) -%}{%- endfor -%} iterates the full collection without ever consulting renderLimit. With a configured renderLimit of 50 ms, a single parseAndRenderSync call has been observed to consume 2.26 seconds (~45× over the limit) and scales linearly with N up to memoryLimit, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration. Deployments that rely on a finite renderLimit for DoS protection (common in multi-tenant template-authoring environments) can still be forced by a single crafted template to monopolize a Node.js event-loop worker for attacker-controlled time, potentially stalling in-flight requests, with availability impact only. This issue has been fixed in version 10.26.0.

Severity

6.5 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator (v2.0.3)

CWE

CWE-400 - Uncontrolled Resource Consumption

Assigner

GitHub_M

References

3 references

URL	Tags
https://github.com/harttle/liquidjs/security/advi…	x_refsource_CONFIRM
https://github.com/harttle/liquidjs/commit/5b9c34…	x_refsource_MISC
https://github.com/harttle/liquidjs/releases/tag/…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
harttle	liquidjs	Affected: < 10.26.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-44645",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-18T19:05:03.703365Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-18T19:05:32.418Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "liquidjs",
          "vendor": "harttle",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 10.26.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "LiquidJS is a Shopify/GitHub Pages compatible template engine written in pure JavaScript. In versions 10.25.7 and below, the renderLimit option can be fully bypassed by a {% for %} (or {% tablerow %}) tag whose body is empty. The renderLimit option is documented in docs/source/tutorials/dos.md as the mechanism that \"mitigates this by limiting the time consumed by each render() call.\" The per-iteration time check is reached only when the body contains at least one template node, so a template such as {%- for i in (1..N) -%}{%- endfor -%} iterates the full collection without ever consulting renderLimit. With a configured renderLimit of 50 ms, a single parseAndRenderSync call has been observed to consume 2.26 seconds (~45\u00d7 over the limit) and scales linearly with N up to memoryLimit, allowing a low-privileged template author to wedge an event-loop thread for an attacker-chosen duration. Deployments that rely on a finite renderLimit for DoS protection (common in multi-tenant template-authoring environments) can still be forced by a single crafted template to monopolize a Node.js event-loop worker for attacker-controlled time, potentially stalling in-flight requests, with availability impact only. This issue has been fixed in version 10.26.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-400",
              "description": "CWE-400: Uncontrolled Resource Consumption",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-17T22:08:19.354Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3"
        },
        {
          "name": "https://github.com/harttle/liquidjs/commit/5b9c3469085e01c79e2d0af28e2a13f730e1793d",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/harttle/liquidjs/commit/5b9c3469085e01c79e2d0af28e2a13f730e1793d"
        },
        {
          "name": "https://github.com/harttle/liquidjs/releases/tag/v10.26.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/harttle/liquidjs/releases/tag/v10.26.0"
        }
      ],
      "source": {
        "advisory": "GHSA-8xx9-69p8-7jp3",
        "discovery": "UNKNOWN"
      },
      "title": "LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-44645",
    "datePublished": "2026-06-17T22:08:19.354Z",
    "dateReserved": "2026-05-07T15:30:10.875Z",
    "dateUpdated": "2026-06-18T19:05:32.418Z",
    "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.

Action not permitted

GHSA-8XX9-69P8-7JP3

Summary

Details

PoC

Impact

Recommended Fix

CVE-2026-44645 (GCVE-0-2026-44645)

Tags

Sightings

Nomenclature