GHSA-p498-v437-472g: humanfs Remote Code Execution Vulnerability
MODERATEGHSA-p498-v437-472g is a MODERATE remote code execution vulnerability (CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) affecting humanfs libraries in the npm ecosystem. The issue involves recursive copy follows symlinked files and copies data from outside the source tree. Remediation is available by upgrading affected packages to version 0.16.8.
GHSA-p498-v437-472g at a Glance
How to Fix GHSA-p498-v437-472g
To remediate this vulnerability, upgrade all affected humanfs dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
npm install @humanfs/node@0.16.8
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
npm ls @humanfs/node
How to Check if You Are Affected
To determine whether your Node.js application is affected by GHSA-p498-v437-472g, inspect your project dependencies using npm:
npm ls @humanfs/node
Analyze the terminal output to locate any version of humanfs in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.16.8), your application is affected.
Note: The npm ls @humanfs/node command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), where 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. In humanfs, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
GHSA-p498-v437-472g Affected humanfs Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
@humanfs/node
|
npm |
< 0.16.8
|
0.16.8
|
References
Frequently Asked Questions
What is GHSA-p498-v437-472g?
Which humanfs versions are affected?
What version fixes GHSA-p498-v437-472g?
Is @humanfs/node affected?
What CWE is associated with GHSA-p498-v437-472g?
How can I check npm dependencies for GHSA-p498-v437-472g?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-p498-v437-472g",
"modified" : "2026-09-02T14:27:16Z",
"published" : "2026-09-02T14:27:16Z",
"aliases" : [ ],
"summary" : "humanfs: Recursive copy follows symlinked files and copies data from outside the source tree",
"details" : "### Summary\n\n`@humanfs/node` does not treat symlinks as a separate case during copy operations. A symlink placed inside an attacker-controlled source tree can make `copyAll()` read and copy the contents of any file readable by the process, even when that file is outside the directory being copied.\n\n### Details\n\nThe Node implementation exposes symlink state through `list()`, but `copyAll()` ignores it. During recursive copies, every non-directory entry is passed to `copy()`, which delegates to `fs.promises.copyFile()`.\n\nOn Node, `copyFile()` dereferences symlinks. As a result, a symlink inside the copied tree is handled as if it were an ordinary file, and the destination receives the contents of the symlink target rather than a copy of the link itself.\n\nThat breaks the expected boundary of a directory copy. A caller can point `copyAll()` at a seemingly self-contained directory and still end up copying data from elsewhere on the host filesystem if the source tree contains attacker-supplied symlinks.\n\nThe same dereference behavior also affects `copy()` when the source path itself is a symlink.\n\n### PoC\n\n```js\nimport { NodeHfs } from \"@humanfs/node\";\nimport fs from \"node:fs/promises\";\nimport path from \"node:path\";\nimport os from \"node:os\";\n\nconst root = await fs.mkdtemp(path.join(os.tmpdir(), \"humanfs-\"));\nconst src = path.join(root, \"src\");\nconst dst = path.join(root, \"dst\");\nconst secret = path.join(root, \"secret.txt\");\n\nawait fs.mkdir(src);\nawait fs.writeFile(secret, \"TOPSECRET\");\nawait fs.symlink(secret, path.join(src, \"link.txt\"));\n\nconst hfs = new NodeHfs();\nawait hfs.copyAll(src, dst);\n\nconsole.log(await fs.readFile(path.join(dst, \"link.txt\"), \"utf8\"));\n// TOPSECRET\n```\n\n### Impact\n\nIf an application uses `copyAll()` or `copy()` on attacker-controlled paths, a symlink can be used to pull arbitrary readable host files into the copied output. In practice, that can turn a normal workspace copy, export, or packaging step into a file disclosure primitive.",
"severity" : [ {
"type" : "CVSS_V4",
"score" : "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "npm",
"name" : "@humanfs/node"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "0.16.8"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/humanwhocodes/humanfs/security/advisories/GHSA-p498-v437-472g"
}, {
"type" : "WEB",
"url" : "https://github.com/humanwhocodes/humanfs/commit/22bbaa4487a3e6c1197ca619840de4615d0c3404"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/humanwhocodes/humanfs"
}, {
"type" : "WEB",
"url" : "https://github.com/humanwhocodes/humanfs/releases/tag/node-v0.16.8"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-22" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-09-02T14:27:16Z",
"nvd_published_at" : null
}
}