LiquidJS CVE-2026-106120

Exploitation requires the ownPropertyOnly LiquidJS option to be ENABLED (it is the very protection being bypassed) AND the attacker to control or influence prototype state (e.g., a polluted Array.prototype) or inherited array-index data on a scope array. The attacker must additionally be able to cause a template to render one of the specific affected operations: negative indexing (arr[-1]), the .first/.last accessors, the first/last/join/reverse/slice/compact filters, or {% for %} iteration. Limiting factors: this is strictly a confidentiality exposure (no write/DoS); direct positive indexing and ordinary object-prototype reads remain blocked and are NOT exploitable; and the flaw is inert on applications that do not enable ownPropertyOnly or that are not already subject to prototype pollution - reflected by the AT:P (attack requirement) and PR:L metrics.

This is a genuine but moderate-severity information-disclosure flaw (CVSS 4.0 base 6.0, Medium) rather than a top-tier priority. The vendor-provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H) tells a nuanced story: network-reachable and low-complexity, BUT it carries AT:P (a specific attack requirement) and PR:L (low-privilege authentication), and impact is confined to confidentiality (VI:N/VA:N) with no scope change. The AT:P flag is the key risk-limiter and aligns with the description, which requires the attacker to influence prototype state or inherited array-index data - i.e., some pre-existing prototype pollution or attacker-controlled inherited data must already be present. No EPSS score, CISA KEV listing, or public POC is present in the supplied intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The signals are internally consistent (no CVSS-vs-description conflict), and the primary caveat is that real-world risk depends heavily on whether ownPropertyOnly is enabled AND the application is already exposed to prototype pollution - a compound precondition that makes widespread opportunistic exploitation unlikely and points toward targeted, environment-specific abuse. Treat as a defense-in-depth hardening fix: patch during normal cycles, prioritizing deployments that rely on ownPropertyOnly as a security boundary for untrusted data.

In an application that renders Liquid templates with ownPropertyOnly enabled to shield an untrusted object, an attacker who can pollute Array.prototype (or otherwise supply inherited array-index data) crafts or triggers a template that uses an 'affected' array path - for example {{ arr.first }}, {{ arr | last }}, {{ arr[-1] }}, or a {% for %} loop. These paths bypass readJSProperty() and read the prototype-provided element, disclosing data that ownPropertyOnly was expected to hide. No public exploit code was identified in the provided intelligence; the attack is low-complexity once the prototype-pollution precondition (AT:P) and low-privilege template influence are satisfied.