CWE-61
AllowedUNIX Symbolic Link (Symlink) Following
Abstraction: Compound · Status: Incomplete
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.
277 vulnerabilities reference this CWE, most recent first.
GHSA-3WGQ-WRWC-VQMV
Vulnerability from github – Published: 2025-09-23 17:45 – Updated: 2025-11-18 16:40Impact
In versions 0.5.3 and earlier of astral-tokio-tar, tar archives may extract outside of their intended destination directory when using the Entry::unpack_in_raw API. Additionally, the Entry::allow_external_symlinks control (which defaults to true) could be bypassed via a pair of symlinks that individually point within the destination but combine to point outside of it.
These behaviors could be used individually or combined to bypass the intended security control of limiting extraction to the given directory. This in turn would allow an attacker with a malicious tar archive to perform an arbitrary file write and potentially pivot into code execution (e.g. by overwriting a file that the user or system then executes or uses to execute code).
The impact of this vulnerability for downstream API users of this crate is high, per above. However, for this crate's main downstream user (uv), the impact of this vulnerability is low due to its overlap with equivalent user capabilities in source distributions. See GHSA-7j9j-68r2-f35q for additional details.
Patches
Versions 0.5.4 and newer of astral-tokio-tar address the vulnerability above. Users should upgrade to 0.5.4 or newer.
Workarounds
Users are advised to upgrade to version 0.5.4 or newer to address this advisory.
There is no workaround other than upgrading.
References
- See GHSA-7j9j-68r2-f35q for how this vulnerability affects uv, astral-tokio-tar's primary downstream user. Observe that unlike this advisory, uv's advisory is considered low severity due to overlap with intentional existing capabilities in source distributions.
- This vulnerability is similar to (but not related in code) to CVE-2025-4138 and CVE-2025-4517, which concern Python's tarfile module.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.3"
},
"package": {
"ecosystem": "crates.io",
"name": "astral-tokio-tar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-59825"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-23T17:45:07Z",
"nvd_published_at": "2025-09-23T20:15:33Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nIn versions 0.5.3 and earlier of astral-tokio-tar, tar archives may extract outside of their intended destination directory when using the `Entry::unpack_in_raw` API. Additionally, the `Entry::allow_external_symlinks` control (which defaults to `true`) could be bypassed via a pair of symlinks that individually point within the destination but combine to point outside of it.\n\nThese behaviors could be used individually or combined to bypass the intended security control of limiting extraction to the given directory. This in turn would allow an attacker with a malicious tar archive to perform an arbitrary file write and potentially pivot into code execution (e.g. by overwriting a file that the user or system then executes or uses to execute code). \n\nThe impact of this vulnerability for downstream API users of this crate is **high**, per above. However, for this crate\u0027s main downstream user (uv), the impact of this vulnerability is **low** due to its overlap with equivalent user capabilities in source distributions. See GHSA-7j9j-68r2-f35q for additional details.\n\n### Patches\n\nVersions 0.5.4 and newer of astral-tokio-tar address the vulnerability above. Users should upgrade to 0.5.4 or newer.\n\n### Workarounds\n\nUsers are advised to upgrade to version 0.5.4 or newer to address this advisory.\n\nThere is no workaround other than upgrading.\n\n### References\n\n* See GHSA-7j9j-68r2-f35q for how this vulnerability affects uv, astral-tokio-tar\u0027s primary downstream user. Observe that **unlike** this advisory, uv\u0027s advisory is considered **low severity** due to overlap with intentional existing capabilities in source distributions.\n* This vulnerability is similar to (but not related in code) to CVE-2025-4138 and CVE-2025-4517, which concern Python\u0027s tarfile module.",
"id": "GHSA-3wgq-wrwc-vqmv",
"modified": "2025-11-18T16:40:30Z",
"published": "2025-09-23T17:45:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/astral-sh/tokio-tar/security/advisories/GHSA-3wgq-wrwc-vqmv"
},
{
"type": "WEB",
"url": "https://github.com/google/security-research/security/advisories/GHSA-9p78-p5g6-gcj8"
},
{
"type": "WEB",
"url": "https://github.com/astral-sh/uv/issues/12163"
},
{
"type": "WEB",
"url": "https://github.com/astral-sh/tokio-tar/commit/036fdecc85c52458ace92dc9e02e9cef90684e75"
},
{
"type": "PACKAGE",
"url": "https://github.com/astral-sh/tokio-tar"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "astral-tokio-tar has a path traversal in tar extraction"
}
GHSA-3X6M-3GRH-599C
Vulnerability from github – Published: 2026-05-08 21:31 – Updated: 2026-05-15 18:30A chmod call in the cPanel Nova plugin's Cpanel::Nova::Connector follows symlinks, allowing setting root permissions on arbitrary system files or directories. That can cause DoS or local privilege escalation when an authenticated cPanel user places a symlink at a user-controlled legacy Nova path under their home directory.
{
"affected": [],
"aliases": [
"CVE-2026-29203"
],
"database_specific": {
"cwe_ids": [
"CWE-61"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T19:16:30Z",
"severity": "HIGH"
},
"details": "A chmod call in the cPanel Nova plugin\u0027s Cpanel::Nova::Connector follows symlinks, allowing setting root permissions on arbitrary system files or directories. That can cause DoS or local privilege escalation when an authenticated cPanel user places a symlink at a user-controlled legacy Nova path under their home directory.",
"id": "GHSA-3x6m-3grh-599c",
"modified": "2026-05-15T18:30:30Z",
"published": "2026-05-08T21:31:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29203"
},
{
"type": "WEB",
"url": "https://support.cpanel.net/hc/en-us/articles/40311543760407-Security-CVE-2026-29203-cPanel-WHM-WP2-Security-Update-May-08-2026"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-459F-X8VQ-XJJM
Vulnerability from github – Published: 2025-12-08 22:18 – Updated: 2025-12-09 19:17Summary
Symbolic links (symlinks) could be used to access files or directories outside the intended web root folder.
Details
SWS generally does not prevent symlinks from escaping the web server’s root directory. Therefore, if a malicious actor gains access to the web server’s root directory, they could create symlinks to access other files outside the designated web root folder either by URL or via the directory listing.
PoC
- Serve a directory (web root) with SWS.
- Create a symlink inside the web root that points to a file outside the web root.
e.g.
ln -s escape.txt $HOME/.bashrc - Open
http://localhost/escape.txtin your browser. - The file content will be served.
Impact
Any web server that runs with elevated privileges (e.g., root/administrator) and handles user-supplied file uploads is primarily impacted.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.40.0"
},
"package": {
"ecosystem": "crates.io",
"name": "static-web-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.40.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67487"
],
"database_specific": {
"cwe_ids": [
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-08T22:18:00Z",
"nvd_published_at": "2025-12-09T16:18:24Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nSymbolic links (_symlinks_) could be used to access files or directories outside the intended web root folder.\n\n### Details\n\nSWS generally does not prevent symlinks from escaping the web server\u2019s root directory. Therefore, if a malicious actor gains access to the web server\u2019s root directory, they could create symlinks to access other files outside the designated web root folder either by URL or via the directory listing.\n\n### PoC\n\n- Serve a directory (web root) with SWS.\n- Create a symlink inside the web root that points to a file outside the web root.\n e.g. `ln -s escape.txt $HOME/.bashrc`\n- Open `http://localhost/escape.txt` in your browser.\n- The file content will be served.\n\n### Impact\n\nAny web server that runs with elevated privileges (e.g., root/administrator) and handles user-supplied file uploads is primarily impacted.",
"id": "GHSA-459f-x8vq-xjjm",
"modified": "2025-12-09T19:17:06Z",
"published": "2025-12-08T22:18:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/static-web-server/static-web-server/security/advisories/GHSA-459f-x8vq-xjjm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67487"
},
{
"type": "WEB",
"url": "https://github.com/static-web-server/static-web-server/commit/308f0d26ceb9c2c8bd219315d0f53914763357f2"
},
{
"type": "PACKAGE",
"url": "https://github.com/static-web-server/static-web-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Static Web Server vulnerable to a symbolic link path traversal"
}
GHSA-4FQP-R85R-HXQH
Vulnerability from github – Published: 2026-01-21 22:19 – Updated: 2026-02-02 16:33Impact
Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the --UNSAFE,--trust flag. As it turns out, a safe template can currently write to arbitrary directories outside the destination path by using directory a symlink along with _preserve_symlinks: true and a generated directory structure whose rendered path is inside the symlinked directory. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user's write permissions), e.g., to cause havoc.
[!NOTE]
At the time of writing, the exploit is non-deterministic, as Copier walks the template's file tree using
os.scandirwhich yields directory entries in arbitrary order.
Reproducible example (may or may not work depending on directory entry yield order):
mkdir other/
pushd other/
echo "sensitive" > sensitive.txt
popd
mkdir src/
pushd src/
ln -s ../other other
echo "overwritten" > "{{ pathjoin('other', 'sensitive.txt') }}.jinja"
echo "_preserve_symlinks: true" > copier.yml
tree .
# .
# ├── copier.yml
# ├── other -> ../other
# └── {{ pathjoin('other', 'sensitive.txt') }}.jinja
#
# 1 directory, 2 files
popd
uvx copier copy --overwrite src/ dst/
cat other/sensitive.txt
# overwritten
Patches
n/a
Workarounds
n/a
References
n/a
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "copier"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.11.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-23986"
],
"database_specific": {
"cwe_ids": [
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-21T22:19:29Z",
"nvd_published_at": "2026-01-21T23:15:52Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nCopier suggests that it\u0027s safe to generate a project from a safe template, i.e. one that doesn\u0027t use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently write to arbitrary directories outside the destination path by using directory a symlink along with [`_preserve_symlinks: true`](https://copier.readthedocs.io/en/stable/configuring/#preserve_symlinks) and a [generated directory structure](https://copier.readthedocs.io/en/stable/configuring/#generating-a-directory-structure) whose rendered path is inside the symlinked directory. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user\u0027s write permissions), e.g., to cause havoc.\n\n\u003e [!NOTE]\n\u003e\n\u003e At the time of writing, the exploit is non-deterministic, as Copier walks the template\u0027s file tree using [`os.scandir`](https://docs.python.org/3/library/os.html#os.scandir) which yields directory entries in arbitrary order.\n\nReproducible example (may or may not work depending on directory entry yield order):\n\n```shell\nmkdir other/\npushd other/\necho \"sensitive\" \u003e sensitive.txt\npopd\n\nmkdir src/\npushd src/\nln -s ../other other\necho \"overwritten\" \u003e \"{{ pathjoin(\u0027other\u0027, \u0027sensitive.txt\u0027) }}.jinja\"\necho \"_preserve_symlinks: true\" \u003e copier.yml\ntree .\n# .\n# \u251c\u2500\u2500 copier.yml\n# \u251c\u2500\u2500 other -\u003e ../other\n# \u2514\u2500\u2500 {{ pathjoin(\u0027other\u0027, \u0027sensitive.txt\u0027) }}.jinja\n#\n# 1 directory, 2 files\npopd\n\nuvx copier copy --overwrite src/ dst/\n\ncat other/sensitive.txt\n# overwritten\n```\n\n### Patches\n\nn/a\n\n### Workarounds\n\nn/a\n\n### References\n\nn/a",
"id": "GHSA-4fqp-r85r-hxqh",
"modified": "2026-02-02T16:33:53Z",
"published": "2026-01-21T22:19:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/copier-org/copier/security/advisories/GHSA-4fqp-r85r-hxqh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23986"
},
{
"type": "WEB",
"url": "https://github.com/copier-org/copier/commit/b3a7b3772d17cf0e7a4481978188c9f536c8d8f6"
},
{
"type": "PACKAGE",
"url": "https://github.com/copier-org/copier"
},
{
"type": "WEB",
"url": "https://github.com/copier-org/copier/releases/tag/v9.11.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Copier safe template has arbitrary filesystem write access via directory symlinks when _preserve_symlinks: true "
}
GHSA-4G74-7CFF-XCV8
Vulnerability from github – Published: 2025-11-05 18:44 – Updated: 2025-11-15 02:25Impact
youki utilizes bind mounting the container's /dev/null as a file mask. When performing this operation, the initial validation of the source /dev/null was insufficient. Specifically, we initially failed to verify whether /dev/null was genuinely present. However, we did perform validation to ensure that the /dev/null path existed within the container, including checking for symbolic links. Additionally, there was a vulnerability in the timing between validation and the actual mount operation.
As a result, by replacing /dev/null with a symbolic link, we can bind-mount arbitrary files from the host system.
This is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems. https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2
Credits
Thanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original runc's vulnerability (Attack 1), and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering another attack vector in runc (Attack 2) based on @ssst0n3's initial findings.
Also, @cyphar helped youki in finding the problem.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "youki"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-62161"
],
"database_specific": {
"cwe_ids": [
"CWE-363",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-05T18:44:18Z",
"nvd_published_at": "2025-11-06T00:15:36Z",
"severity": "HIGH"
},
"details": "### Impact ###\n\nyouki utilizes bind mounting the container\u0027s `/dev/null` as a file mask. When performing this operation, the initial validation of the source `/dev/null` was insufficient. Specifically, we initially failed to verify whether `/dev/null` was genuinely present. However, we did perform validation to ensure that the `/dev/null` path existed within the container, including checking for symbolic links. Additionally, there was a vulnerability in the timing between validation and the actual mount operation.\n\nAs a result, by replacing `/dev/null` with a symbolic link, we can bind-mount arbitrary files from the host system.\n\nThis is a different project, but the core logic is similar to the CVE in runc. Issues were identified in runc, and verification was also conducted in youki to confirm the problems.\nhttps://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2\n\n### Credits\n\nThanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original runc\u0027s vulnerability (Attack 1), and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering another attack vector in runc (Attack 2) based on @ssst0n3\u0027s initial findings.\n\nAlso, @cyphar helped youki in finding the problem.",
"id": "GHSA-4g74-7cff-xcv8",
"modified": "2025-11-15T02:25:02Z",
"published": "2025-11-05T18:44:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2"
},
{
"type": "WEB",
"url": "https://github.com/youki-dev/youki/security/advisories/GHSA-4g74-7cff-xcv8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62161"
},
{
"type": "WEB",
"url": "https://github.com/youki-dev/youki/commit/5886c91073b9be748bd8d5aed49c4a820548030a"
},
{
"type": "PACKAGE",
"url": "https://github.com/youki-dev/youki"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "youki container escape via \"masked path\" abuse due to mount race conditions"
}
GHSA-4Q92-RFM6-2CQX
Vulnerability from github – Published: 2026-02-06 19:08 – Updated: 2026-03-30 19:59Claude Code failed to strictly enforce deny rules configured in settings.json when accessing files through symbolic links. If a user explicitly denied Claude Code access to a file (such as /etc/passwd) and Claude Code had access to a symbolic link pointing to that file, it was possible for Claude Code to read the restricted file through the symlink without triggering deny rule enforcement.
Users on standard Claude Code auto-update received this fix automatically. Users performing manual updates are advised to update to the latest version.
Claude Code thanks https://hackerone.com/ofirh for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@anthropic-ai/claude-code"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25724"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-06T19:08:04Z",
"nvd_published_at": "2026-02-06T18:16:00Z",
"severity": "LOW"
},
"details": "Claude Code failed to strictly enforce deny rules configured in settings.json when accessing files through symbolic links. If a user explicitly denied Claude Code access to a file (such as /etc/passwd) and Claude Code had access to a symbolic link pointing to that file, it was possible for Claude Code to read the restricted file through the symlink without triggering deny rule enforcement. \n\nUsers on standard Claude Code auto-update received this fix automatically. Users performing manual updates are advised to update to the latest version.\n\nClaude Code thanks https://hackerone.com/ofirh for reporting this issue.",
"id": "GHSA-4q92-rfm6-2cqx",
"modified": "2026-03-30T19:59:02Z",
"published": "2026-02-06T19:08:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/anthropics/claude-code/security/advisories/GHSA-4q92-rfm6-2cqx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25724"
},
{
"type": "PACKAGE",
"url": "https://github.com/anthropics/claude-code"
},
{
"type": "WEB",
"url": "https://www.terra.security/blog/when-ai-becomes-the-attack-surface-lessons-from-discovering-cve-2026-25724"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Claude Code has Permission Deny Bypass Through Symbolic Links"
}
GHSA-54R8-8CQ2-5P82
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-07-03 00:00A UNIX Symbolic Link (Symlink) Following vulnerability in the clone-master-clean-up.sh script of clone-master-clean-up in SUSE Linux Enterprise Server 12 SP3, SUSE Linux Enterprise Server 15 SP1; openSUSE Factory allows local attackers to delete arbitrary files. This issue affects: SUSE Linux Enterprise Server 12 SP3 clone-master-clean-up version 1.6-4.6.1 and prior versions. SUSE Linux Enterprise Server 15 SP1 clone-master-clean-up version 1.6-3.9.1 and prior versions. openSUSE Factory clone-master-clean-up version 1.6-1.4 and prior versions.
{
"affected": [],
"aliases": [
"CVE-2021-32000"
],
"database_specific": {
"cwe_ids": [
"CWE-59",
"CWE-61"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-28T10:15:00Z",
"severity": "HIGH"
},
"details": "A UNIX Symbolic Link (Symlink) Following vulnerability in the clone-master-clean-up.sh script of clone-master-clean-up in SUSE Linux Enterprise Server 12 SP3, SUSE Linux Enterprise Server 15 SP1; openSUSE Factory allows local attackers to delete arbitrary files.\nThis issue affects:\nSUSE Linux Enterprise Server 12 SP3\nclone-master-clean-up version 1.6-4.6.1 and prior versions.\nSUSE Linux Enterprise Server 15 SP1\nclone-master-clean-up version 1.6-3.9.1 and prior versions.\nopenSUSE Factory\nclone-master-clean-up version 1.6-1.4 and prior versions.",
"id": "GHSA-54r8-8cq2-5p82",
"modified": "2022-07-03T00:00:23Z",
"published": "2022-05-24T19:09:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32000"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1181050"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-56GF-J26C-43XH
Vulnerability from github – Published: 2024-09-17 00:31 – Updated: 2025-11-04 18:31This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Sequoia 15. An app may be able to break out of its sandbox.
{
"affected": [],
"aliases": [
"CVE-2024-44132"
],
"database_specific": {
"cwe_ids": [
"CWE-59",
"CWE-61"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-17T00:15:50Z",
"severity": "HIGH"
},
"details": "This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Sequoia 15. An app may be able to break out of its sandbox.",
"id": "GHSA-56gf-j26c-43xh",
"modified": "2025-11-04T18:31:21Z",
"published": "2024-09-17T00:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44132"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121238"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Sep/33"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
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"
}
GHSA-5CM7-HHJ8-4M75
Vulnerability from github – Published: 2026-07-23 21:31 – Updated: 2026-07-23 21:31Datasets through 5.00, fixed in commit ad2d853, contains a symlink-following vulnerability in Extractor.extract() that allows local attackers to write arbitrary files by pre-planting symlinks at predictable output paths. Attackers can redirect archive extraction to arbitrary filesystem locations in shared-cache environments, enabling overwrite of sensitive files and potential privilege escalation or code execution.
{
"affected": [],
"aliases": [
"CVE-2026-65010"
],
"database_specific": {
"cwe_ids": [
"CWE-61"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T19:17:03Z",
"severity": "MODERATE"
},
"details": "Datasets through 5.00, fixed in commit ad2d853, contains a symlink-following vulnerability in Extractor.extract() that allows local attackers to write arbitrary files by pre-planting symlinks at predictable output paths. Attackers can redirect archive extraction to arbitrary filesystem locations in shared-cache environments, enabling overwrite of sensitive files and potential privilege escalation or code execution.",
"id": "GHSA-5cm7-hhj8-4m75",
"modified": "2026-07-23T21:31:02Z",
"published": "2026-07-23T21:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65010"
},
{
"type": "WEB",
"url": "https://github.com/huggingface/datasets/issues/8296"
},
{
"type": "WEB",
"url": "https://github.com/huggingface/datasets/pull/8303"
},
{
"type": "WEB",
"url": "https://github.com/huggingface/datasets/commit/ad2d853ae2ce41d8068c23b44c2e29004312ccee"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/datasets-symlink-following-arbitrary-file-write-via-extractor-extract"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
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.
Mitigation MIT-48.1
Strategy: Separation of Privilege
- 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.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.