GHSA-56p5-8mhr-2fph CVE-2026-35525
LiquidJS: Root restriction bypass for partial and layout loading through symlinked templates
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.40%
- Chance of exploitation in the next 30 days. Higher than 33.86% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-61 UNIX Symbolic Link (Symlink) Following
- Fix
10.25.3- Upgrade liquidjs to this version or later
Description
Summary
LiquidJS enforces partial and layout root restrictions using the resolved pathname string, but it does not resolve the canonical filesystem path before opening the file. A symlink placed inside an allowed partials or layouts directory can therefore point to a file outside that directory and still be loaded.
Details
For {% include %}, {% render %}, and {% layout %}, LiquidJS checks whether the candidate path is inside the configured partials or layouts roots before reading it. That check is path-based, not realpath-based.
Because of that, a file like partials/link.liquid passes the directory containment check as long as its pathname is under the allowed root. If link.liquid is actually a symlink to a file outside the allowed root, the filesystem follows the symlink when the file is opened and LiquidJS renders the external target.
So the restriction is applied to the path string that was requested, not to the file that is actually read.
This matters in environments where an attacker can place templates or otherwise influence files under a trusted template root, including uploaded themes, extracted archives, mounted content, or repository-controlled template trees.
PoC
const { Liquid } = require('liquidjs');
const fs = require('fs');
fs.rmSync('/tmp/liquid-root', { recursive: true, force: true });
fs.mkdirSync('/tmp/liquid-root', { recursive: true });
fs.writeFileSync('/tmp/secret-outside.liquid', 'SECRET_OUTSIDE');
fs.symlinkSync('/tmp/secret-outside.liquid', '/tmp/liquid-root/link.liquid');
const engine = new Liquid({ root: ['/tmp/liquid-root'] });
engine.parseAndRender('{% render "link.liquid" %}')
.then(console.log);
// SECRET_OUTSIDE
Impact
If an attacker can place or influence symlinks under a trusted partials or layouts directory, they can make LiquidJS read and render files outside the intended template root. In practice this can expose arbitrary readable files reachable through symlink targets.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| liquidjs | < 10.25.3 |
10.25.3 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
liquidjs npm → 10.25.3
- npm
npm install liquidjs@10.25.3- yarn
yarn add liquidjs@10.25.3- pnpm
pnpm add liquidjs@10.25.3
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-61: UNIX Symbolic Link (Symlink) Following
The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
How to prevent it
- Implementation: Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.
- Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system. Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-fwxr-j5w2-587m LiquidJS: ownPropertyOnly bypass for inherited array indices in first/last/join/reverse/slice/compact, `.first`/`.last`, negative index, and for-loop iteration | Medium | Also affects liquidjs |
| GHSA-4r6h-5v86-94p3 LiquidJS: Uncontrolled Resource Consumption in `join` filter allows template authors to bypass `memoryLimit` and crash the process | High | Also affects liquidjs |
| GHSA-m7fp-h3p4-hr49 LiquidJS has an infinite loop vulnerability in its `strip_html` filter | High | Also affects liquidjs |
| GHSA-g357-x5c3-c72p LiquidJS: `pop` filter bypasses `memoryLimit` accounting that its array-filter siblings enforce | High | Also affects liquidjs |
| GHSA-gf2q-c269-pqgc LiquidJS is Vulnerable to Remote Code Execution | Critical | Also affects liquidjs |
| GHSA-r7g9-xpmj-5fcq LiquidJS Vulnerable to ReDoS via Quadratic Backtracking in `strip_html` Filter Regex | High | Also affects liquidjs |
| GHSA-hh27-hf48-9f5q LiquidJS has a memory and render limit bypass via unbounded width padding in `date` filter (strftime) | High | Also affects liquidjs |
| GHSA-9x9p-qf8f-mvjg LiquidJS's `{% render %}` tag silently bypasses per-render `ownPropertyOnly:true` via `Context.spawn()` | Medium | Also affects liquidjs |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor