[GHSA-92fh-27vv-894w] nanotar is vulnerable to path traversal in parseTar() and parseTarGzip()

[Wenxin-Jiang]

Updates

• Affected products

Comments

0.0.0 is a placeholder with no code

The 0.0.0 tarball on the npm registry (https://registry.npmjs.org/nanotar/-/nanotar-0.0.0.tgz) contains a single file, package.json, whose entire content is {"name":"nanotar","version":"0.0.0"}.

There is no dist/, no JavaScript, and no parseTar/createTar functions, so the path-traversal sink described in CVE-2025-69874 cannot exist.

A PoC against 0.0.0 has nothing to call and will always fail. Including it in the affected range produces false positives for downstream consumers.

0.1.1 is the first release containing the vulnerable code

Between 0.0.0 (2023-12-09 00:17 UTC) and 0.1.1 (2023-12-09 00:18 UTC), the project published the real implementation.

0.1.1 is the earliest version that ships dist/index.{cjs,mjs} and exports:

• parseTar
• parseTarGzip
• createTar

Every subsequent affected version inherits that code path from 0.1.1, so 0.1.1 is the true introduced version.

The fix was first released in 0.2.1, then also in 0.3.0

The advisory currently lists no patched version.

The fix is PR unjs/nanotar#58 ("fix: sanitise paths"), merge commit 322f9677f12c4a5c15eea223bd51542f35a31219, merged 2026-02-11 22:52 UTC.

It adds _sanitizePath(), which:

• strips drive letters
• collapses .. segments
• normalises separators

It is called from parseTar before each entry's name is recorded.

This code ships in both:

• 0.3.0 — published 2026-02-11 22:54:51 UTC (2 minutes after the merge)
• 0.2.1 — published 2026-02-11 23:03:42 UTC (9 minutes after 0.3.0) as a backport to the 0.2.x line

A diff of dist/index.mjs between 0.2.0 and 0.2.1 shows the same _sanitizePath function and the same call-site injection in parseTar.