CVE-2026-106120 in LiquidJS
Summary
by MITRE • 10/06/2026
LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.27.2, enabling ownPropertyOnly does not consistently restrict inherited array indices because negative indexing, .first, .last, the first filter, the last filter, join, reverse, slice, compact, and for-loop iteration can read prototype-provided elements outside readJSProperty(). An attacker who can influence prototype state or inherited array-index data and cause templates to render affected operations can disclose values that ownPropertyOnly is expected to hide. Direct positive indexing and ordinary object prototype reads are blocked, but the alternate array paths remain affected. This issue is fixed in 10.27.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
LiquidJS serves as a widely adopted template engine compatible with platforms such as Shopify and GitHub Pages, written entirely in JavaScript. A significant security flaw was identified within versions prior to 10.27.2 concerning the enforcement of access control policies when the ownPropertyOnly configuration option is enabled. This setting is designed to restrict property access strictly to an object's own properties, thereby preventing templates from inadvertently or maliciously accessing inherited properties from prototype chains. However, the implementation contained a logical inconsistency where this restriction was not consistently applied across all array manipulation methods and iteration mechanisms available within the Liquid template syntax.
The core technical flaw lies in the failure of specific array operations to properly validate property ownership against the configured security policy. While direct positive indexing and standard object prototype reads were correctly blocked by the readJSProperty function, alternative paths for accessing array elements remained vulnerable. Specifically, negative indexing allows access to array elements from the end using negative indices, which can bypass certain boundary checks if not rigorously validated against the prototype chain. Furthermore, built-in filters such as first, last, join, reverse, slice, and compact were found to read inherited array indices that should have been hidden under ownPropertyOnly settings. Additionally, for-loop iterations over arrays could also expose these prototype-provided elements, effectively circumventing the intended isolation of object properties.
The operational impact of this vulnerability is primarily information disclosure. An attacker who can influence the prototype state or inject data into inherited array-index structures within a Liquid template context may exploit these alternate access paths to retrieve sensitive values that are supposed to be hidden by the ownPropertyOnly restriction. This could lead to the exposure of internal application states, configuration details, or other confidential data embedded in object prototypes. The severity is heightened because many web applications rely on strict separation between user-controlled input and internal framework objects, assuming that such isolation mechanisms like ownPropertyOnly provide a robust security boundary against prototype pollution attacks or unauthorized property access.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically relating to the failure to enforce restrictions on data access for unintended entities. It also relates to CWE-915, concerning Improper Modification of Objects During Deserialization if the vector involves manipulating object prototypes through input processing. In terms of threat modeling and attack techniques, this flaw facilitates aspects of ATT&CK technique T1078, Valid Accounts or System Information Discovery, as it allows an attacker to gather information about the system's internal structure that should remain opaque. The issue underscores the importance of comprehensive validation across all code paths in template engines, ensuring that security configurations are applied uniformly regardless of the method used to access data structures.
The vulnerability has been addressed and fixed in version 10.27.2 of LiquidJS. Developers utilizing this library must upgrade to this patched version or later to ensure that ownPropertyOnly restrictions are consistently enforced across all array operations, including negative indexing, filters like first and last, and iteration loops. Until the update is applied, mitigation strategies should include strict input validation on any data passed into templates, avoiding the use of complex object prototypes in template contexts where possible, and reviewing application logic to ensure that no sensitive information relies solely on ownPropertyOnly for protection against prototype-based access vectors. Regular security audits and dependency updates are essential practices to maintain resilience against such logical flaws in widely used software components.