CVE-2026-30952

What it actually does

LiquidJS versions prior to 10.25.0 allow the layout, render, and include tags to resolve absolute file paths. If an attacker can control template content, or can control an included file path through a Liquid variable when dynamicPartials is enabled, the template engine may read arbitrary files from the server filesystem. The primary impact is unauthorized file disclosure, such as application configuration, secrets, source code, service account tokens, local system files, or other files readable by the application process. The vulnerability is remotely reachable in applications that expose template rendering or template path selection to untrusted users and does not require authentication, user interaction, or high attack complexity in those exposed scenarios.

Why it matters to the business

Successful exploitation can expose sensitive business data and operational secrets stored on the application host, including credentials that may enable further compromise of databases, cloud services, source repositories, or internal APIs. For organizations using LiquidJS in user-customizable templates, CMS features, email/page builders, documentation generators, or storefront-like rendering flows, the issue can create a direct data exposure path. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, but the CVSS severity is high because exploitation is simple wherever untrusted users can influence templates or include paths.

How an attack unfolds

An attacker first identifies an application feature backed by LiquidJS, such as user-editable templates, themes, page snippets, emails, previews, or any parameter that influences an include, render, or layout path. They then submit Liquid syntax that references an absolute path, or provide an absolute path through a variable consumed by one of those tags. In vulnerable versions, LiquidJS resolves that absolute path instead of restricting file access to the intended template directories. The application renders the referenced file contents into the HTTP response, preview output, generated document, email body, or an error/log side channel. The attacker repeats the process with likely sensitive paths, such as environment files, application configuration files, source files, cloud credential files, or system account files, and uses any recovered secrets to expand access beyond the initial file disclosure.

How to fix it

Upgrade LiquidJS to version 10.25.0 or later wherever it is used, including direct and transitive dependencies in npm, yarn, pnpm, container images, serverless packages, and bundled application artifacts. If immediate upgrade is not possible, prevent untrusted users from controlling Liquid template source, include paths, layout paths, or render paths; disable dynamic partial selection where feasible; reject absolute paths and path traversal sequences before rendering; enforce a strict allowlist of template names; and ensure template resolution is confined to approved template root directories. Run the application with least-privilege filesystem permissions so the rendering process cannot read secrets or unrelated system files. Avoid storing high-value secrets on local disk where the application runtime can read them, and rotate any credentials if exploitation is suspected.

How to confirm the fix worked

Confirm all deployed applications resolve LiquidJS to 10.25.0 or later using package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls liquidjs, yarn why liquidjs, pnpm why liquidjs, SCA tooling, and container image scans. Verify that no vulnerable copy is bundled into build artifacts or vendored JavaScript packages. Add regression tests that attempt to render absolute paths through include, render, and layout tags and confirm the engine rejects them or confines resolution to approved template directories. Review application configuration to confirm untrusted users cannot submit arbitrary Liquid templates or arbitrary partial paths. For internet-facing applications, perform a controlled test against non-sensitive canary files outside the template directory to confirm they cannot be read.

Typical attack path

1. Find an application feature that renders LiquidJS templates or accepts template include/layout/render paths.
2. Confirm that untrusted input is evaluated as Liquid template content or as a Liquid variable used for partial selection.
3. Submit a payload using an absolute path in a layout, render, or include tag, or pass an absolute path through a variable when dynamicPartials is enabled.
4. Observe whether file contents, parsing errors, or path resolution errors are returned in the application response or generated output.
5. Iterate over sensitive local paths readable by the application process, such as configuration files, environment files, source code, SSH keys, cloud credentials, or system files.
6. Use disclosed credentials or internal data for follow-on access, privilege escalation, lateral movement, or data theft.

How to detect it

Look for evidence that users supplied Liquid template tags or variables referencing absolute filesystem paths. Useful sources include application access logs, request bodies captured by WAF/API gateways, template rendering logs, preview or CMS audit logs, exception traces, reverse proxy logs, and EDR file-access telemetry for the application process. Search for include, render, or layout tags containing Unix-style absolute paths, Windows drive paths, UNC paths, or sensitive file names. Also review errors generated by the Node.js process, such as ENOENT or EACCES for unexpected absolute paths, because failed exploitation attempts often produce file-open errors. If EDR file telemetry is available, investigate the application process reading files outside approved template directories shortly after web requests containing Liquid syntax. If suspicious access is found, determine whether the file contents were returned in responses, generated documents, emails, or logs, and rotate any secrets that may have been exposed.

• {% include '/etc/passwd' %}
• {% render '/etc/passwd' %}
• {% layout '/etc/passwd' %}
• {% include "/etc/passwd" %}
• {% render "/etc/passwd" %}
• {% layout "/etc/passwd" %}
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /proc/self/environ
• /proc/1/environ
• /app/.env
• /.env
• /var/run/secrets/kubernetes.io/serviceaccount/token
• /root/.aws/credentials
• /home/node/.aws/credentials
• /home/app/.aws/credentials
• C:\\Windows\\win.ini
• C:\\Windows\\System32\\drivers\\etc\\hosts
• C:\\Users\\Administrator\\.aws\\credentials
• \\\\localhost\\c$
• ENOENT: no such file or directory, open '/'
• EACCES: permission denied, open '/'
• dynamicPartials
• {% include
• {% render
• {% layout

What your security team should do

• Prioritize upgrade to LiquidJS 10.25.0 or later for internet-facing or multi-tenant applications that allow user-controlled templates, themes, snippets, emails, previews, or partial names.
• Inventory all direct and transitive uses of LiquidJS across source repositories, lockfiles, containers, CI/CD artifacts, and serverless bundles.
• Treat applications with dynamicPartials enabled and user-controlled include/render/layout variables as highest exposure until patched or mitigated.
• Add input validation or allowlisting so template names are logical identifiers, not filesystem paths.
• Restrict the application runtime account to the minimum filesystem access required and remove readable secrets from local disk where possible.
• Review recent application, WAF, reverse proxy, and template rendering logs for absolute-path include attempts and sensitive file read probes.
• If suspicious reads are found, rotate potentially exposed secrets such as API keys, database passwords, cloud credentials, signing keys, and service tokens.
• Add automated SCA policy gates to block LiquidJS versions earlier than 10.25.0 in future builds.