CVE-2026-39859
Path Traversal in LiquidJS renderFile() Allows Arbitrary File Access
Publication date: 2026-04-08
Last updated on: 2026-04-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| liquidjs | liquidjs | to 10.25.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-22 | The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows arbitrary file read by bypassing the configured root directory restriction, enabling attackers to access files outside the intended sandbox.
Such unauthorized access to local files could lead to exposure of sensitive or personal data, which may violate data protection regulations like GDPR or HIPAA if the compromised files contain protected information.
Therefore, applications using vulnerable versions of liquidjs that rely on the root option as a sandbox boundary and pass attacker-controlled template names to renderFile() or parseFile() risk non-compliance with these standards due to potential data breaches.
Can you explain this vulnerability to me?
CVE-2026-39859 is a vulnerability in the liquidjs npm package (versions up to and including 10.25.4) that allows an attacker to read arbitrary files on the server. This happens because the top-level file loading functions renderFile() and parseFile() do not properly enforce the configured root directory restriction, allowing files outside the intended sandbox to be accessed.
Although liquidjs documents that the root option should constrain filenames, the enforcement is missing for top-level file loads. This means that even if a Liquid instance is configured with a safe temporary directory as root, an attacker can bypass this and read sensitive files like /etc/hosts by passing absolute paths to these functions.
The root cause is that the code disables the enforceRoot flag for top-level file lookups, accepting resolved paths without verifying if they reside within the root directory. This contrasts with stricter checks applied to partial, layout, and include lookups.
How can this vulnerability impact me? :
This vulnerability can lead to unauthorized disclosure of sensitive local files on the server where liquidjs is used. An attacker who can control template names passed to renderFile() or parseFile() can read arbitrary files outside the intended sandbox.
Such file disclosure can expose configuration files, credentials, or other sensitive data, potentially leading to further attacks or data breaches.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by testing whether the LiquidJS instance allows reading files outside the configured root directory using the renderFile() or parseFile() functions.
A practical detection method is to attempt rendering a file outside the root directory, such as /etc/hosts, and observe if the contents are returned.
For example, if you have access to the application code or a testing environment, you can run a script that calls renderFile('/etc/hosts') on a Liquid instance configured with a safe temporary directory as root. If the file contents are returned, the vulnerability is present.
There are no specific network commands provided in the resources, but monitoring for unexpected file read operations or unusual template rendering requests that include absolute paths could help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade liquidjs to version 10.25.3 or later, where the vulnerability is fixed by enforcing containment checks on top-level file loads.
If upgrading is not immediately possible, avoid configuring Liquid instances with an empty or unsafe root directory and do not pass untrusted or attacker-controlled template names to renderFile() or parseFile().
Additionally, review your application code to ensure that the root directory option is properly set and that template file paths are validated to prevent path traversal.