Skip to content
Heist/ feed
Back to feed
MediumFix available

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

Type: advisorySources: OSV

## 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: ```ts // src/render/render.ts 14: public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator { 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.

Products
liquidjs
Affected versions
Not specified
Fixed versions
10.26.0
CVEs
CVE-2026-44645
Confirmed fixed CVEs
Not specified
Updated in this feed
1 Nov 2026, 18:43 UTC · Revision 1

Source evidence

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

core-osv · Original source

Published 27 May 2026, 00:11 UTC

## 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: ```ts // src/render/render.ts 14: public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator { 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.

osv:GHSA-8xx9-69p8-7jp3

liquidjs

Fixed versions: 10.26.0

Complete source record
{
  "id": "ff657af1bad873696a6987fa9370e90f14e595cfe163942a301afb0dd85025d3",
  "url": "https://osv.dev/vulnerability/GHSA-8xx9-69p8-7jp3",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "LiquidJS has a renderLimit DoS guard bypass via empty `{% for %}` body",
    "summary": "## 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: ```ts // src/render/render.ts 14: public * renderTemplates (templates: Template[], ctx: Context, emitter?: Emitter): IterableIterator { 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. ",
    "evidence": "osv:GHSA-8xx9-69p8-7jp3",
    "products": [
      {
        "name": {
          "value": "liquidjs",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "10.26.0",
            "evidence": "/affected/0/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "medium",
    "structured": {
      "id": "GHSA-8xx9-69p8-7jp3",
      "aliases": [
        "CVE-2026-44645",
        "GHSA-8xx9-69p8-7jp3"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "SEMVER",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "fixed": "10.26.0"
                }
              ]
            }
          ],
          "package": {
            "name": "liquidjs",
            "purl": "pkg:npm/liquidjs",
            "ecosystem": "npm"
          },
          "database_specific": {
            "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/05/GHSA-8xx9-69p8-7jp3/GHSA-8xx9-69p8-7jp3.json"
          }
        }
      ],
      "modified": "2026-10-27T15:15:08.159614848Z",
      "provider": "osv",
      "references": [
        "https://github.com/harttle/liquidjs/security/advisories/GHSA-8xx9-69p8-7jp3",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-44645",
        "https://github.com/harttle/liquidjs/commit/5b9c3469085e01c79e2d0af28e2a13f730e1793d",
        "https://github.com/harttle/liquidjs",
        "https://github.com/harttle/liquidjs/blob/v10.26.0/CHANGELOG.md",
        "https://github.com/harttle/liquidjs/releases/tag/v10.26.0"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-400"
        ],
        "severity": "MODERATE",
        "github_reviewed": true,
        "nvd_published_at": "2026-06-17T23:17:03Z",
        "github_reviewed_at": "2026-05-27T00:11:46Z"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-44645",
        "evidence": "/aliases"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 462825,
  "published_at": "2026-05-27T00:11:46+00:00"
}