CVE-2026-39412

What it actually does

LiquidJS versions prior to 10.25.4 allow the sort_natural filter to bypass the ownPropertyOnly security option. When ownPropertyOnly: true is used to prevent templates from reading inherited prototype properties, this flaw still lets a template author infer or extract values from prototype-inherited properties via sorting behavior. The result is a confidentiality issue: untrusted template input can disclose sensitive values that should not be visible to the template, such as inherited API keys, tokens, configuration secrets, or framework-level properties.

Why it matters to the business

Applications that let users, tenants, customers, or integrations submit LiquidJS templates may unintentionally expose secrets or cross-tenant data if they rely on ownPropertyOnly as a security boundary. The likely consequence is information leakage rather than service disruption or system takeover, but exposed API keys or tokens could enable follow-on compromise of connected services. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so prioritization should be risk-based, with higher urgency for multi-tenant template rendering, user-authored themes, CMS/email-template builders, and SaaS customization features.

How an attack unfolds

An attacker needs the ability to provide or modify a LiquidJS template that is rendered by a vulnerable application. They craft template logic that uses the sort_natural filter against objects or values whose inherited prototype properties should be hidden by ownPropertyOnly: true. Because the filter does not correctly enforce the own-property restriction, the attacker can observe sorting outcomes as a side channel and iteratively infer inherited property values. If sensitive data such as API keys, tokens, or configuration values are stored on object prototypes or inherited objects passed into the rendering context, the attacker can recover those values and use them outside the template engine for unauthorized access or further reconnaissance.

How to fix it

Upgrade LiquidJS to version 10.25.4 or later everywhere it is used, including direct application dependencies and bundled/transitive copies in front-end or server-side packages. If immediate upgrade is not possible, treat ownPropertyOnly: true as insufficient for untrusted templates and apply compensating controls: disable or remove the sort_natural filter for untrusted template authors, avoid rendering untrusted LiquidJS templates, pass only sanitized plain objects with null prototypes into the render context, never place secrets or tenant-sensitive values on prototypes or inherited objects, and isolate template rendering in a restricted execution context. Rotate any secrets that may have been exposed through template-rendering features if exploitation is suspected.

How to confirm the fix worked

Confirm dependency resolution shows LiquidJS 10.25.4 or later in all package manifests, lockfiles, deployed artifacts, containers, and serverless bundles. Use package tooling such as npm ls liquidjs, yarn why liquidjs, pnpm why liquidjs, or software composition analysis to identify all copies. Add a regression test that renders an untrusted template using sort_natural while ownPropertyOnly: true is enabled and verifies inherited prototype properties cannot affect output or be inferred. Review template-rendering configuration to confirm untrusted users cannot access dangerous context objects and that no secrets are stored on prototypes or inherited objects passed into LiquidJS.

Typical attack path

1. Identify an application feature that renders user-controlled LiquidJS templates, such as custom themes, email templates, CMS content, reports, or tenant-specific layouts.
2. Determine or assume that the application uses LiquidJS before version 10.25.4 and relies on ownPropertyOnly: true to restrict template access.
3. Submit a crafted template that invokes the sort_natural filter on data influenced by inherited prototype properties.
4. Use observed rendering differences, ordering changes, errors, or output variations as a side channel to infer hidden inherited property values.
5. Repeat the probing process to reconstruct sensitive prototype-inherited values such as tokens, API keys, or configuration secrets.
6. Use any recovered secrets for follow-on access to application functions, third-party services, or other protected resources.

How to detect it

To determine whether this was already exploited, review logs and storage locations that capture user-authored LiquidJS templates, template revisions, preview/render requests, CMS or theme edits, email-template changes, and API requests that update templates. Look for use of sort_natural in templates submitted by untrusted users, especially combined with attempts to reference inherited or prototype-related names such as __proto__, prototype, constructor, toString, valueOf, or secret-like property names. Examine application logs for repeated template preview/render requests with small changes, unusual rendering errors around sorting, high-frequency template edits, or output-differential probing from the same account, IP address, API token, or session. If the application logs rendered output or template errors, search for leaked values or partial guesses of API keys, tokens, bearer strings, cloud credentials, webhook secrets, or integration credentials. Because this is an information-disclosure side channel, there may be no network-level exploit signature; the strongest evidence will usually be suspicious template content, repeated render attempts, and subsequent use of exposed secrets in application or third-party service logs.

• sort_natural
• ownPropertyOnly
• __proto__
• prototype
• constructor
• toString
• valueOf
• hasOwnProperty
• apiKey
• api_key
• accessToken
• access_token
• secret
• token
• Bearer
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• LIQUIDJS
• liquidjs

What your security team should do

• Prioritize upgrade to LiquidJS 10.25.4 or later for internet-facing or multi-tenant applications that allow user-controlled templates.
• Inventory all applications and packages that use LiquidJS, including transitive dependencies and embedded copies in build artifacts.
• Search repositories and deployed configuration for ownPropertyOnly: true and sort_natural usage to identify likely exposure points.
• Temporarily disable the sort_natural filter or block untrusted template editing where upgrade cannot be completed quickly.
• Review recent user-submitted templates for probing patterns involving sort_natural, prototype access, constructor access, __proto__, and repeated sorting-based comparisons.
• If suspicious template activity is found, rotate potentially exposed API keys, tokens, and integration secrets and investigate downstream service access logs.
• Harden template-rendering design by passing minimal, sanitized, plain data objects into templates and keeping secrets out of render contexts entirely.