CVE-2026-39859

What it actually does

LiquidJS versions 10.25.0 through 10.25.2 incorrectly documented the configured root directory as constraining filenames passed to top-level renderFile() and parseFile(), but those top-level file loads did not enforce the boundary. If an application passes attacker-influenced filenames into those APIs, an unauthenticated remote attacker may traverse outside the intended template root and read arbitrary files accessible to the application process. The impact is confidentiality-focused: local file disclosure such as configuration files, secrets, environment files, source code, or system files. Integrity and availability are not directly affected by the flaw as described.

Why it matters to the business

Applications using affected LiquidJS versions may unintentionally expose sensitive server-side files if template filenames can be influenced by users or external input. This can lead to disclosure of credentials, API keys, configuration secrets, source code, or internal data, which may enable follow-on compromise even though the vulnerability itself is read-only. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity, but it has been public for over 120 days, so internet-facing or multi-tenant services that render Liquid templates should prioritize verification and upgrade.

How an attack unfolds

An attacker first identifies an application feature that renders Liquid templates from a filename, theme name, document path, layout value, or similar user-controllable input. If the application uses LiquidJS 10.25.0, 10.25.1, or 10.25.2 and calls renderFile() or parseFile() with that input, the attacker supplies path traversal sequences or absolute paths that point outside the configured root directory. Because the vulnerable top-level file load does not enforce the root boundary, LiquidJS may open and return the targeted file if the Node.js process has filesystem permissions to read it. The attacker then uses disclosed files, such as environment files, service credentials, source code, package manifests, or cloud configuration, to support further intrusion or credential abuse.

How to fix it

Upgrade LiquidJS to version 10.25.3 or later wherever it is used. Because the vulnerability affects library behavior, patch all direct and transitive deployments that include affected versions, then rebuild and redeploy application artifacts. In addition to upgrading, ensure applications do not pass untrusted input directly to renderFile() or parseFile(); use strict allowlists for template names, map user-facing identifiers to server-side filenames, normalize and validate resolved paths, and reject absolute paths or traversal sequences. Run services with least-privilege filesystem access so the rendering process cannot read secrets or unrelated system files. If immediate upgrade is not possible, disable user-controlled file rendering, restrict reachable template names to a fixed set, and place sensitive configuration and credential files outside the permissions of the application runtime where feasible.

How to confirm the fix worked

Confirm that package manifests, lockfiles, container images, build artifacts, and runtime dependency inventories no longer contain liquidjs versions 10.25.0, 10.25.1, or 10.25.2, and that deployed applications use 10.25.3 or later. Review code for LiquidJS renderFile() and parseFile() calls and verify that filenames are not directly derived from request parameters, route variables, uploaded content metadata, or external API input. Perform a controlled negative test in a non-production environment by attempting to render paths outside the configured root, such as parent-directory traversal strings or harmless operating-system marker files; the application should reject the request or return a safe error without disclosing file contents. Validate container and server filesystem permissions to ensure the application account cannot read unrelated secrets or sensitive host files.

Typical attack path

1. Identify an application or service that uses LiquidJS for server-side template rendering.
2. Find a request parameter, route component, uploaded template reference, theme setting, or API field that influences the filename passed to renderFile() or parseFile().
3. Submit traversal or absolute-path payloads targeting files outside the configured LiquidJS root directory.
4. Confirm file disclosure by retrieving predictable files such as package metadata, application configuration, or operating system marker files.
5. Extract higher-value secrets such as environment files, credentials, tokens, private keys, or source code if readable by the application process.
6. Use disclosed secrets or internal knowledge for lateral movement, cloud access, source-code compromise, or additional application attacks.

How to detect it

Investigate web, API gateway, reverse proxy, application, and Node.js service logs for requests that include traversal sequences or absolute filesystem paths in parameters associated with templates, layouts, themes, pages, filenames, includes, views, or render operations. Focus on time periods after deployment of LiquidJS 10.25.0 through 10.25.2 and especially after public disclosure. Look for successful responses with unusually large body sizes, text/plain or download-like responses from template-rendering routes, repeated probing for operating-system marker files, or requests that target configuration and secret files. Review application error logs for ENOENT, EACCES, path resolution, or file-read errors containing unexpected paths outside the intended template root. If request bodies are logged, search JSON and form fields for '../', '..\\', absolute Unix paths, Windows drive paths, and encoded traversal. In endpoint or container telemetry, investigate Node.js processes reading files outside the application template directory, particularly .env files, cloud credential files, SSH keys, package metadata, or system files shortly after suspicious web requests.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e%5c
• ..%2f
• ..%5c
• /etc/passwd
• /etc/hosts
• /proc/self/environ
• /proc/self/cmdline
• /app/.env
• /.env
• /var/run/secrets/kubernetes.io/serviceaccount/token
• /root/.ssh/id_rsa
• /home/node/.ssh/id_rsa
• /home/node/.aws/credentials
• C:\\Windows\\win.ini
• C:\\Windows\\System32\\drivers\\etc\\hosts
• file:///etc/passwd
• file://C:/Windows/win.ini
• ENOENT
• EACCES
• renderFile
• parseFile
• liquidjs@10.25.0
• liquidjs@10.25.1
• liquidjs@10.25.2
• "liquidjs": "10.25.0"
• "liquidjs": "10.25.1"
• "liquidjs": "10.25.2"

What your security team should do

• Inventory all applications, services, containers, serverless functions, and build pipelines that include the liquidjs package.
• Upgrade LiquidJS to 10.25.3 or later and redeploy affected workloads.
• Prioritize internet-facing, multi-tenant, customer-extensible, CMS, documentation, theme, email-template, and static-site generation services where users can influence template selection.
• Search codebases for renderFile() and parseFile() and require allowlisted template resolution rather than direct use of external input.
• Review logs for path traversal probes, absolute path attempts, and unexpected reads of sensitive files around template-rendering endpoints.
• Rotate credentials if logs, monitoring, or forensic review indicates files such as environment files, cloud credentials, private keys, or application configuration may have been disclosed.
• Add dependency scanning or software composition analysis rules to block liquidjs versions before 10.25.3 in future builds.
• Harden runtime permissions so the Node.js process can only read intended template directories and required application files.