CVE-2026-53655

What it actually does

node-tar before 7.5.16 incorrectly applies PAX extended header overrides, including the PAX size= value, to the immediately following tar header even when that header is an intermediary GNU long-name or long-link metadata entry. POSIX pax semantics require the PAX header to describe the next real file entry, not extension headers inserted before that file. This creates a parser interpretation differential: node-tar advances its stream cursor differently than GNU tar, libarchive/bsdtar, Python tarfile, and other corrected tar implementations. A crafted archive can therefore present one set of members to node-tar and a different set to other tools, enabling hidden files, misclassified archive contents, or inconsistent extraction/scanning outcomes.

Why it matters to the business

Organizations that inspect, package, upload, unpack, or scan tar archives with Node.js tooling may have security controls bypassed when different components disagree about what an archive contains. This can allow malicious files, secrets, policy-violating content, or unexpected package contents to evade scanners and later be extracted or consumed by downstream automation. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or mature public exploitation reported, but the issue is relevant for CI/CD systems, artifact repositories, package ingestion services, malware scanning pipelines, and any workflow that treats archive inspection results as a security boundary.

How an attack unfolds

An attacker creates a tar archive containing a PAX extended header with a size= override and places a GNU long-name, GNU long-link, or another intermediary metadata header between the PAX header and the intended file entry. A standards-compliant tar parser treats the PAX metadata as applying to the subsequent real file, while vulnerable node-tar applies the override to the intermediary header and advances its stream cursor incorrectly. The attacker then arranges subsequent bytes so that node-tar and another tar implementation enumerate or extract different members. If a security workflow scans with one parser but extracts, publishes, deploys, or validates with another, the attacker can hide a payload from the scanner while ensuring it appears in the downstream extraction path, or hide benign-looking content from the extractor while showing it to inspection tooling.

How to fix it

Upgrade node-tar to version 7.5.16 or later everywhere it is used directly or transitively. Regenerate lockfiles and rebuild dependent applications, containers, CLI tools, CI images, and serverless artifacts so the corrected package is actually deployed. If immediate upgrade is not possible, avoid using mixed tar parsers across security boundaries: use the same patched library for both scanning and extraction, or perform extraction in a sandbox and scan the exact extracted filesystem tree rather than relying only on archive member listings. Treat tar archive uploads as untrusted input, enforce allowlisted file paths and expected file types after extraction, reject archives containing PAX extended headers combined with GNU long-name/long-link entries where feasible, and isolate archive processing from privileged paths and production credentials.

How to confirm the fix worked

Confirm package inventories and lockfiles show tar/node-tar version 7.5.16 or later, including transitive dependencies. Run dependency scanners such as npm audit, npm ls tar, pnpm why tar, or yarn why tar across source repositories, build images, and deployed artifacts. Validate runtime containers and packaged applications, not just source manifests, because vulnerable versions may be bundled. For functional validation, process a crafted regression archive containing a PAX size= header followed by GNU long-name/long-link metadata and confirm node-tar produces the same member list and extraction behavior as GNU tar or bsdtar. Review archive processing pipelines to ensure security checks operate on the same parsed/extracted representation that downstream systems consume.

Typical attack path

1. Identify a target workflow that accepts tar archives and uses node-tar before 7.5.16 in at least one inspection, listing, extraction, packaging, or validation step.
2. Determine whether the workflow uses multiple tar parsers, such as node-tar for extraction and GNU tar, libarchive, Python tarfile, or another implementation for scanning or inventory.
3. Craft a tar archive with a PAX extended header containing size= or related override records before a GNU long-name, GNU long-link, or intermediary metadata header.
4. Place malicious, sensitive, or policy-violating archive members after the desynchronizing header sequence so different parsers disagree on the member list or extraction result.
5. Submit the archive through an upload, build, package, artifact, dependency, or scanning pipeline.
6. Rely on the scanner or gatekeeper seeing a harmless archive while the downstream extractor or consumer processes the hidden or differently interpreted member.

How to detect it

There are no universal host-level indicators proving exploitation, because successful use typically appears as normal archive upload, scanning, or extraction activity. Investigate by correlating archive ingestion logs, CI/CD job logs, artifact repository events, upload service logs, malware scanner results, and extraction logs for the same archive hash and looking for mismatched file inventories or scan-versus-extract discrepancies. Preserve suspicious tar inputs and compare member listings and extracted output across node-tar, GNU tar, bsdtar/libarchive, and Python tarfile. Focus on archives containing PAX extended headers with size= records followed by GNU long-name or long-link entries, especially if submitted to systems that use node-tar before 7.5.16. Look for scanner logs that marked an archive clean while downstream extraction, build, or deployment logs reference additional files not present in the scanner inventory. In forensic review, search retained uploaded archives, build workspaces, package staging directories, and artifact caches for unexpected files appearing after extraction, path allowlist violations, newly introduced executable scripts, package lifecycle hooks, or files absent from prior archive inventory records.

• size=
• ././@LongLink
• PaxHeaders
• typeflag=x followed by GNU long-name typeflag=L
• typeflag=x followed by GNU long-link typeflag=K
• PAX extended header followed by ././@LongLink
• GNU LongLink
• GNU LongName

What your security team should do

• Prioritize upgrading node-tar to 7.5.16 or later in CI/CD, package ingestion, artifact repository, malware scanning, upload processing, and deployment automation paths.
• Search software composition analysis results, lockfiles, container images, and build tooling for vulnerable tar/node-tar versions before 7.5.16.
• Review archive security workflows for parser mismatch: identify places where one tool lists or scans tar contents and another tool extracts or consumes them.
• Temporarily route untrusted tar extraction through a sandbox and scan the post-extraction filesystem tree using the same output that downstream systems will use.
• Add detection or quarantine rules for tar archives containing PAX extended headers with size= records adjacent to GNU long-name or long-link headers.
• Reprocess or rescan recently accepted untrusted tar archives if they were used in security-sensitive workflows while vulnerable node-tar versions were deployed.
• Monitor upstream advisories and dependency updates for downstream tools that bundle node-tar, because the vulnerable library may be included indirectly.