Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
21 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
node-tar (npm tar) contains an uncontrolled-recursion stack-exhaustion DoS in the internal mapHas helper used by filesFilter. When a consumer calls tar.t(...) or tar.x(...) with a non-empty member-selection list, node-tar installs a filter that closes over the recursive mapHas (src/list.ts:33-44). mapHas walks an entry path upward one path.dirname() call per recursion with no segment cap. A single crafted tar with a GNU-L (or PAX-x) long-path header can deliver a path of tens of thousands of /-separated segments (up to maxMetaEntrySize = 1 MiB). The recursion overflows the call stack, throwing an uncatchable RangeError that terminates the Node process on async/streaming consumers. Root Cause filesFilter (src/list.ts:27-51) is installed whenever a caller passes a member-selection list (src/list.ts:119-122, src/extract.ts:55-57). Its filter is invoked at src/parse.ts:253 (entry.ignore = entry.ignore || !this.filter(entry.path, entry)) inside Parser[CONSUMEHEADER] — and…
Recommended action: Upgrade to 7.5.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A crafted 2.5KB tar archive crashes any Node.js process that extracts it. The PAX header parser coerces all-digit path values to JavaScript numbers, which causes an uncaught TypeError when downstream code calls .split('/') on the numeric value. Error handlers and strict: false cannot intercept the crash. Details In pax.ts line 180, parseKV converts PAX values matching /^[0-9]+$/ to numbers via +v. This applies to all fields including path and linkpath. When a PAX header sets path to an all-digit string like "12345", the value becomes the number 12345. This number flows through Header - ReadEntry - Unpack.CHECKPATH, where normalizeWindowsPath(entry.path).split('/') throws a TypeError because numbers don't have .split(). The throw is synchronous during event emission and bypasses all error handling: - strict: false does not help - 'error' event handlers do not catch it - 'warn' handlers do not catch it - The TypeError propagates through the event emitter stack as an…
Recommended action: Upgrade to 7.5.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Decompression/parse DoS via unlimited input vulnerability in node-tar allows an attacker to exhaust server resources (disk space and CPU). Because the library does not enforce hard upper bounds on total decompressed data or entry counts, a small, maliciously crafted "Gzip Bomb" can be used to fill a server's storage and crash services. Details The node-tar library does not enforce a hard upper bound on archive size or the volume of decompressed data processed during extraction. While the maxReadSize option exists, it only controls internal read chunk sizes (default 16MB) and does not limit the total cumulative bytes written to disk. Specifically, in src/extract.ts, the Unpack stream processes entries as they arrive. There is no total-bytes limit, entry-count limit, or decompression ratio guard. An attacker can provide a TAR header claiming a massive file size (e.g., 10GB) and follow it with highly compressible data (like zeros). node-tar will continue to extract and write…
Recommended action: Upgrade to 7.5.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A checksum-valid tar archive with a negative base-256 encoded entry size can make tar.replace() loop forever while scanning the existing archive. Applications that update attacker-controlled tar archives can have a worker process pinned indefinitely, causing denial of service. Details The public tar.replace() API scans the existing archive before appending replacement entries. During this scan, it parses each tar header and advances the archive position by the parsed entry size rounded to a 512-byte block boundary. Tar supports base-256 encoded numeric fields. A crafted header can encode the entry size as -512 while still carrying a valid checksum. The replace scan accepts that parsed negative size and uses it in the position-advance calculation. For a size of -512, the computed body skip is -512. The scan then adds the normal 512-byte header step, resulting in no net progress. The scanner repeatedly parses the same header forever and never reaches the append step. This is…
Recommended action: Upgrade to 7.5.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
node-tar strips trailing NUL bytes from long-name (L) and long-linkpath (K) GNU extended headers but does not apply the same sanitization to equivalent fields delivered via PAX (x typeflag) extended headers. A PAX record of the form path=visible.txt\x00hidden.txt is parsed verbatim into entry.path and flows into fs.lstat() / fs.open(), which Node.js core rejects with ERRINVALIDARGVALUE. The throw originates inside an FSReqCallback async chain that is not wrapped by the consumer's await/try-catch around tar.x() — it surfaces as uncaughtException and terminates the process. This is a remote denial-of-service primitive against any process that extracts attacker-supplied tarballs through tar.x / tar.extract / tar.t / tar.Parser, even when the consumer follows the documented try/catch error-handling pattern. A secondary parser-differential (CWE-436) exists because tar(1), bsdtar, and Python tarfile truncate the path at the first NUL (yielding visible.txt) while node-tar retains…
Recommended action: Upgrade to 7.5.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
tar (node-tar) applies a PAX extended header's size= record (and other PAX overrides) to the next header entry of any type, including intermediary metadata headers such as a GNU long-name (L) or long-link (K) entry. Per POSIX pax, a PAX extended header (x) describes the next file entry, not the intermediary extension headers that may sit between the x header and the file it annotates. Because node-tar lets the PAX size override the byte length of an intervening L/K/x header, an attacker can desynchronize node-tar's stream cursor relative to every other mainstream tar implementation (GNU tar, libarchive/bsdtar, Python tarfile, and the now-fixed tar-rs / astral-tokio-tar). The result is a tar parser interpretation differential (CWE-436): a single crafted archive yields a different set of members under node-tar than under the reference tar tools. An attacker can use this to hide a member from one parser while it is visible to another, which defeats security tooling whose scanner…
Recommended action: Upgrade to 7.5.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
tar (npm) can be tricked into creating a symlink that points outside the extraction directory by using a drive-relative symlink target such as C:../../../target.txt, which enables file overwrite outside cwd during normal tar.x() extraction. Details The extraction logic in Unpack[STRIPABSOLUTEPATH] validates .. segments against a resolved path that still uses the original drive-relative value, and only afterwards rewrites the stored linkpath to the stripped value. What happens with linkpath: "C:../../../target.txt": 1. stripAbsolutePath() removes C: and rewrites the value to ../../../target.txt. 2. The escape check resolves using the original pre-stripped value, so it is treated as in-bounds and accepted. 3. Symlink creation uses the rewritten value (../../../target.txt) from nested path a/b/l. 4. Writing through the extracted symlink overwrites the outside file (../target.txt). This is reachable in standard usage (tar.x({ cwd, file })) when extracting attacker-controlled tar…
Recommended action: Upgrade to 7.5.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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): Run: Observed output: PWNED confirms outside file content overwrite. Link count 2 confirms the extracted file…
Recommended action: Upgrade to 7.5.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
tar.extract() in Node tar allows an attacker-controlled archive to create a hardlink inside the extraction directory that points to a file outside the extraction root, using default options. This enables arbitrary file read and write as the extracting user (no root, no chmod, no preservePaths). Severity is high because the primitive bypasses path protections and turns archive extraction into a direct filesystem access primitive. Details The bypass chain uses two symlinks plus one hardlink: 1. a/b/c/up - ../.. 2. a/b/escape - c/up/../.. 3. exfil (hardlink) - a/b/escape/<target-relative-to-parent-of-extract Why this works: - Linkpath checks are string-based and do not resolve symlinks on disk for hardlink target safety. - See STRIPABSOLUTEPATH logic in: - ../tar-audit-setuid - CVE/nodemodules/tar/dist/commonjs/unpack.js:255 - ../tar-audit-setuid - CVE/nodemodules/tar/dist/commonjs/unpack.js:268 - ../tar-audit-setuid - CVE/nodemodules/tar/dist/commonjs/unpack.js:281 - Hardlink…
Recommended action: Upgrade to 7.5.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
node-tar contains a vulnerability where the security check for hardlink entries uses different path resolution semantics than the actual hardlink creation logic. This mismatch allows an attacker to craft a malicious TAR archive that bypasses path traversal protections and creates hardlinks to arbitrary files outside the extraction directory. Details The vulnerability exists in lib/unpack.js. When extracting a hardlink, two functions handle the linkpath differently: Security check in [STRIPABSOLUTEPATH]: Hardlink creation in [HARDLINK]: Example: An application extracts a TAR using tar.extract({ cwd: '/var/app/uploads/' }). The TAR contains entry a/b/c/d/x as a hardlink to ../../../../etc/passwd. - Security check resolves the linkpath relative to the entry's parent directory: a/b/c/d/ + ../../../../etc/passwd = etc/passwd. No ../ prefix, so it passes. - Hardlink creation resolves the linkpath relative to the extraction directory (this.cwd): /var/app/uploads/ +…
Recommended action: Upgrade to 7.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
TITLE: Race Condition in node-tar Path Reservations via Unicode Sharp-S (ß) Collisions on macOS APFS AUTHOR: Tomás Illuminati Details A race condition vulnerability exists in node-tar (v7.5.3) this is to an incomplete handling of Unicode path collisions in the path-reservations system. On case-insensitive or normalization-insensitive filesystems (such as macOS APFS, In which it has been tested), the library fails to lock colliding paths (e.g., ß and ss), allowing them to be processed in parallel. This bypasses the library's internal concurrency safeguards and permits Symlink Poisoning attacks via race conditions. The library uses a PathReservations system to ensure that metadata checks and file operations for the same path are serialized. This prevents race conditions where one entry might clobber another concurrently. In MacOS the FS confuses ß with ss, but this code does not. For example: bash bash-3.2$ printf "CONTENTSS\n" collisiontestss bash-3.2$ ls collisiontestss bash-3.2$…
Recommended action: Upgrade to 7.5.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The node-tar library (<= 7.5.2) fails to sanitize the linkpath of Link (hardlink) and SymbolicLink entries when preservePaths is false (the default secure behavior). This allows malicious archives to bypass the extraction root restriction, leading to Arbitrary File Overwrite via hardlinks and Symlink Poisoning via absolute symlink targets. Details The vulnerability exists in src/unpack.ts within the [HARDLINK] and [SYMLINK] methods. 1. Hardlink Escape (Arbitrary File Overwrite) The extraction logic uses path.resolve(this.cwd, entry.linkpath) to determine the hardlink target. Standard Node.js behavior dictates that if the second argument (entry.linkpath) is an absolute path, path.resolve ignores the first argument (this.cwd) entirely and returns the absolute path. The library fails to validate that this resolved target remains within the extraction root. A malicious archive can create a hardlink to a sensitive file on the host (e.g., /etc/passwd) and subsequently write to it,…
Recommended action: Upgrade to 7.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using .t (aka .list) with { sync: true } to read tar entry contents returns uninitialized memory contents if tar file was changed on disk to a smaller size while being read. Details See: https://github.com/isaacs/node-tar/issues/445 https://github.com/isaacs/node-tar/pull/446 Regression happened in https://github.com/isaacs/node-tar/commit/5330eb04bc43014f216e5c271b40d5c00d45224d PoC A: B (vulnerable): Run A and B in parallel on Node.js 22 or =25.1.0 Dumps B memory (wait for some time to observe text data) Impact Exposes process memory and could result in e.g. unintentionally (aka attacker-controlled) attempting to process sensitive data rather than tar entry contents. Uninitialized memory can contain unrelated file contents, environment variables, passwords, etc. To execute, an attacker must reduce the file size to boundary between a tar header and body block, in the time between when the tar archive file size is read via stat, and the time when the tar archive parser…
Recommended action: Upgrade to 7.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
During some analysis today on npm's node-tar package I came across the folder creation process, Basicly if you provide node-tar with a path like this ./a/b/c/foo.txt it would create every folder and sub-folder here a, b and c until it reaches the last folder to create foo.txt, In-this case I noticed that there's no validation at all on the amount of folders being created, that said we're actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside Steps To Reproduce: You can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video Proof Of Concept: Here's a video show-casing the exploit: Impact Denial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources…
Recommended action: Upgrade to 6.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created. This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory, where the symlink and directory names in the archive entry used backslashes as a path separator on posix systems. The cache checking logic used both \ and / characters as path separators, however \ is a valid filename character on posix systems. By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on directories, essentially allowing an…
Recommended action: Upgrade to 6.1.7, 5.0.8 or 4.4.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created. This logic was insufficient when extracting tar files that contained two directories and a symlink with names containing unicode values that normalized to the same value. Additionally, on Windows systems, long path portions would resolve to the same file system entities as their 8.3 "short path" counterparts. A specially crafted tar archive could thus include directories with two forms of the path that resolve to the same file system entity, followed by a symbolic link with a name in the first form, lastly followed by a file using the second form. It led to…
Recommended action: Upgrade to 6.1.9, 5.0.10 or 4.4.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution node-tar aims to guarantee that any file whose location would be outside of the extraction target directory is not extracted. This is, in part, accomplished by sanitizing absolute paths of entries within the archive, skipping archive entries that contain .. path portions, and resolving the sanitized paths against the extraction target directory. This logic was insufficient on Windows systems when extracting tar files that contained a path that was not an absolute path, but specified a drive letter different from the extraction target, such as C:some\path. If the drive letter does not match the extraction target, for example D:\extraction\dir, then the result of path.resolve(extractionDirectory, entryPath) would resolve against the current working directory on the C: drive, rather than the extraction target directory. Additionally, a .. portion of the path could occur immediately after the drive letter,…
Recommended action: Upgrade to 6.1.9, 5.0.10 or 4.4.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution node-tar aims to prevent extraction of absolute file paths by turning absolute paths into relative paths when the preservePaths flag is not set to true. This is achieved by stripping the absolute path root from any absolute file paths contained in a tar file. For example /home/user/.bashrc would turn into home/user/.bashrc. This logic was insufficient when file paths contained repeated path roots such as ////home/user/.bashrc. node-tar would only strip a single path root from such paths. When given an absolute file path with repeating path roots, the resulting path (e.g. ///home/user/.bashrc) would still resolve to an absolute path, thus allowing arbitrary file creation and overwrite. Patches 3.2.2 || 4.4.14 || 5.0.6 || 6.1.1 NOTE: an adjacent issue CVE-2021-32803 affects this release level. Please ensure you update to the latest patch levels that address CVE-2021-32803 as well if this adjacent issue…
Recommended action: Upgrade to 6.1.1, 5.0.6, 4.4.14 or 3.2.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created. This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory. This order of operations resulted in the directory being created and added to the node-tar directory cache. When a directory is present in the directory cache, subsequent calls to mkdir for that directory are skipped. However, this is also where node-tar checks for symlinks occur. By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on…
Recommended action: Upgrade to 6.1.2, 5.0.7, 4.4.15 or 3.2.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of tar prior to 4.4.2 for 4.x and 2.2.2 for 2.x are vulnerable to Arbitrary File Overwrite. Extracting tarballs containing a hardlink to a file that already exists in the system, and a file that matches the hardlink will overwrite the system's file with the contents of the extracted file. Recommendation For tar 4.x, upgrade to version 4.4.2 or later. For tar 2.x, upgrade to version 2.2.2 or later.
Recommended action: Upgrade to 4.4.2 or 2.2.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of tar prior to 2.0.0 are affected by an arbitrary file write vulnerability. The vulnerability occurs because tar does not verify that extracted symbolic links to not resolve to targets outside of the extraction root directory. Recommendation Update to version 2.0.0 or later
Recommended action: Upgrade to 2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.