GHSA-56P5-8MHR-2FPH
Vulnerability from github – Published: 2026-04-08 15:03 – Updated: 2026-04-10 21:34Summary
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": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.25.2"
},
"package": {
"ecosystem": "npm",
"name": "liquidjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.25.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35525"
],
"database_specific": {
"cwe_ids": [
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T15:03:47Z",
"nvd_published_at": "2026-04-08T20:16:24Z",
"severity": "HIGH"
},
"details": "### Summary\n\nLiquidJS 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.\n\n### Details\n\nFor `{% 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.\n\nBecause 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.\n\nSo the restriction is applied to the path string that was requested, not to the file that is actually read.\n\nThis 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.\n\n### PoC\n\n```js\nconst { Liquid } = require(\u0027liquidjs\u0027);\nconst fs = require(\u0027fs\u0027);\n\nfs.rmSync(\u0027/tmp/liquid-root\u0027, { recursive: true, force: true });\nfs.mkdirSync(\u0027/tmp/liquid-root\u0027, { recursive: true });\n\nfs.writeFileSync(\u0027/tmp/secret-outside.liquid\u0027, \u0027SECRET_OUTSIDE\u0027);\nfs.symlinkSync(\u0027/tmp/secret-outside.liquid\u0027, \u0027/tmp/liquid-root/link.liquid\u0027);\n\nconst engine = new Liquid({ root: [\u0027/tmp/liquid-root\u0027] });\n\nengine.parseAndRender(\u0027{% render \"link.liquid\" %}\u0027)\n .then(console.log);\n// SECRET_OUTSIDE\n```\n\n### Impact\n\nIf 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.",
"id": "GHSA-56p5-8mhr-2fph",
"modified": "2026-04-10T21:34:31Z",
"published": "2026-04-08T15:03:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-56p5-8mhr-2fph"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35525"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/pull/867"
},
{
"type": "PACKAGE",
"url": "https://github.com/harttle/liquidjs"
},
{
"type": "WEB",
"url": "https://github.com/harttle/liquidjs/releases/tag/v10.25.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "LiquidJS: Root restriction bypass for partial and layout loading through symlinked templates"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.