PT-2026-43626 · Npm · Liquidjs

Published

2026-05-27

·

Updated

2026-05-27

·

CVE-2026-44646

CVSS v3.1

5.3

Medium

VectorAV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Summary

Context.spawn() in liquidjs creates a child Context for the {% render %} tag but does not propagate the parent context's resolved ownPropertyOnly value. The new context re-derives ownPropertyOnly from opts.ownPropertyOnly (the instance-level option), silently discarding any RenderOptions.ownPropertyOnly override that was supplied to parseAndRender(). As a result, a developer who runs a Liquid instance with the backwards-compatible ownPropertyOnly:false and then locks down an untrusted render with parseAndRender(..., { ownPropertyOnly: true }) still leaks prototype-chain properties from inside any {% render %} partial. This is a distinct exploit surface from the previously identified array-filter variants (where, reject, group by, find, find index, has) — the underlying root cause in Context.spawn() is shared, but {% render %} is a separately reachable sink that needs no filter usage.

Details

The bug is in Context.spawn():
// src/context/context.ts:105-114
public spawn (scope = {}) {
 return new Context(scope, this.opts, {
  sync: this.sync,
  globals: this.globals,
  strictVariables: this.strictVariables
  // <-- ownPropertyOnly is missing here
 }, {
  renderLimit: this.renderLimit,
  memoryLimit: this.memoryLimit
 })
}
The constructor resolves ownPropertyOnly as:
// src/context/context.ts:47
this.ownPropertyOnly = renderOptions.ownPropertyOnly ?? opts.ownPropertyOnly
Because spawn() passes a RenderOptions object with no ownPropertyOnly, the child context falls back to opts.ownPropertyOnly (the instance-level option), throwing away any per-render override that the parent context had applied. this.opts is the raw normalized instance options object; it is not mutated to reflect render-time overrides.
The {% render %} tag at src/tags/render.ts:51-77 calls spawn() to build the partial's isolated scope:
* render (ctx: Context, emitter: Emitter): Generator<unknown, void, unknown> {
 const { liquid, hash } = this
 const filepath = (yield renderFilePath(this['file'], ctx, liquid)) as string
 assert(filepath, () => `illegal file path "${filepath}"`)

 const childCtx = ctx.spawn()          // <-- ownPropertyOnly lost here
 const scope = childCtx.bottom()
  assign(scope, yield hash.render(ctx))
 ...
 const templates = (yield liquid. parsePartialFile(filepath, childCtx.sync, this['currentFile'])) as Template[]
 yield liquid.renderer.renderTemplates(templates, childCtx, emitter)
}
All template variable lookups inside the partial then go through childCtx.readProperty() (src/context/context.ts:123-135), which calls readJSProperty(obj, key, this.ownPropertyOnly). With childCtx.ownPropertyOnly === false (inherited from opts), the protective check at src/context/context.ts:138-141 is skipped and prototype-chain properties are returned to the template:
export function readJSProperty (obj: Scope, key: PropertyKey, ownPropertyOnly: boolean) {
 if (ownPropertyOnly && !hasOwnProperty.call(obj, key) && !(obj instanceof Drop)) return undefined
 return obj[key]
}
The {% include %} tag is not affected: it does not call spawn(); it pushes onto the parent context's scope stack (src/tags/include.ts:40), so the parent's resolved ownPropertyOnly continues to apply.
Trust model / why this matters: RenderOptions.ownPropertyOnly is documented (src/liquid-options.ts:108-111) as "Same as ownPropertyOnly on LiquidOptions, but only for current render() call". It exists precisely so that developers running a non-strict instance can lock down individual untrusted renders. That contract is broken — the override is silently dropped at every partial boundary.

PoC

mkdir -p /tmp/render-poc
printf '{{ user.passwordHash }}' > /tmp/render-poc/ user.liquid

node -e "
const { Liquid } = require('./dist/liquid.node.js');
const liquid = new Liquid({ ownPropertyOnly: false, root: '/tmp/render-poc' });

class User { constructor(n){ this.name = n; } }
User.prototype.passwordHash = 'bcrypt$secret';
const u = new User('alice');

liquid.parseAndRender(
 'Direct:[{{ user.passwordHash }}] Render:[{% render " user.liquid", user: user %}]',
 { user: u },
 { ownPropertyOnly: true }
).then(console.log);
"
Verified output on liquidjs 10.25.7:
Direct:[] Render:[bcrypt$secret]
The top-level expression {{ user.passwordHash }} is correctly blocked by the per-render ownPropertyOnly:true, but the same expression inside the partial loaded by {% render %} returns the prototype-chain property — proof that Context.spawn() discarded the override.

Impact

  • Information disclosure: Any prototype-chain property of objects passed into a {% render %} partial — including secrets, hashes, internal state, framework-injected helpers — becomes readable from inside the partial template, even when the developer used the documented per-render lockdown.
  • Realistic threat model: Applications that maintain ownPropertyOnly:false for backwards compatibility (or because their data layer relies on prototype methods) and lock down untrusted-template renders with parseAndRender(..., { ownPropertyOnly:true }) are protected at the top level but silently exposed inside any partial. User-controllable template content (CMS snippets, theme partials, email templates) that uses {% render %} becomes an info-leak primitive.
  • Distinct from existing CVE-2022-25948: the prior advisory only covered direct use of ownPropertyOnly:false; this is a failure of the documented mitigation (ownPropertyOnly:true per-render override), not a missing setting.
  • Distinct from the array-filter variant: same spawn() root cause, but exploitable without invoking where/reject/group by/find/find index/has — only requires that the template uses {% render %} (a basic templating feature) and that one of the rendered values has prototype-chain properties.

Recommended Fix

Propagate ownPropertyOnly (and any other security-relevant render options) inside Context.spawn():
// src/context/context.ts
public spawn (scope = {}) {
 return new Context(scope, this.opts, {
  sync: this.sync,
  globals: this.globals,
  strictVariables: this.strictVariables,
  ownPropertyOnly: this.ownPropertyOnly  // <-- propagate resolved per-render value
 }, {
  renderLimit: this.renderLimit,
  memoryLimit: this.memoryLimit
 })
}
Passing this.ownPropertyOnly (the resolved value, not this.opts.ownPropertyOnly) ensures any RenderOptions.ownPropertyOnly override flows into spawned child contexts. This single change closes both the {% render %} pathway documented here and the array-filter pathway tracked separately. A regression test should assert that a partial rendered via {% render %} honours parseAndRender(..., { ownPropertyOnly: true }) against an object with prototype-chain properties.

Fix

Protection Mechanism Failure

Weakness Enumeration

CWE-693

Related Identifiers

CVE-2026-44646
GHSA-9X9P-QF8F-MVJG

Affected Products

Liquidjs