Vulnerabilities in pkg:npm/@humanfs/node

PACKAGE
Advisory Summary

GHSA-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.

1 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:npm/@humanfs/node

1 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:npm/@humanfs/node. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-p498-v437-472g - MODERATE humanfs: Recursive copy follows symlinked files and copies data from outside the source tree

GHSA-p498-v437-472g at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-p498-v437-472g
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Affected Product humanfs
Package Ecosystem npm
Published Date
Last Updated

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.

@humanfs/node fixed: 0.16.8
npm install @humanfs/node@0.16.8
Verify Direct and Transitive Dependencies

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

### Summary `@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. ### Details The 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()`. On 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. That 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. The same dereference behavior also affects `copy()` when the source path itself is a symlink. ### PoC ```js import { NodeHfs } from "@humanfs/node"; import fs from "node:fs/promises"; import path from "node:path"; import os from "node:os"; const root = await fs.mkdtemp(path.join(os.tmpdir(), "humanfs-")); const src = path.join(root, "src"); const dst = path.join(root, "dst"); const secret = path.join(root, "secret.txt"); await fs.mkdir(src); await fs.writeFile(secret, "TOPSECRET"); await fs.symlink(secret, path.join(src, "link.txt")); const hfs = new NodeHfs(); await hfs.copyAll(src, dst); console.log(await fs.readFile(path.join(dst, "link.txt"), "utf8")); // TOPSECRET ``` ### Impact If 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.

GHSA-p498-v437-472g Affected humanfs Versions

1 component(s)
Fixed Versions:
0.16.8
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?
GHSA-p498-v437-472g is a security vulnerability in humanfs involving Recursive copy follows symlinked files and copies data from outside the source tree under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
Which humanfs versions are affected?
Affected versions include releases prior to 0.16.8 across affected packages: @humanfs/node.
What version fixes GHSA-p498-v437-472g?
Upgrading to 0.16.8 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @humanfs/node affected?
Yes, @humanfs/node is affected in releases prior to 0.16.8. Upgrade your dependency to 0.16.8 or later.
What CWE is associated with GHSA-p498-v437-472g?
GHSA-p498-v437-472g is classified under CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (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.).
How can I check npm dependencies for GHSA-p498-v437-472g?
Run the dependency tree command: 'npm ls @humanfs/node'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "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
  }
}