Bug 2491423 (CVE-2026-53655) - CVE-2026-53655 node-tar: node-tar: File smuggling due to inconsistent tar archive parsing
Summary: CVE-2026-53655 node-tar: node-tar: File smuggling due to inconsistent tar arc...
Keywords:
Status: NEW
Alias: CVE-2026-53655
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 2498648 2498649 2498650 2498651 2498653 2498654 2498655 2498656 2498657 2498659 2498660 2498661 2498662 2498663 2498669 2498671 2498673 2498675 2498676 2498680 2498682 2498685 2498686 2498652 2498658 2498664 2498665 2498666 2498667 2498668 2498670 2498672 2498674 2498677 2498678 2498679 2498681 2498683 2498684
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-06-22 16:02 UTC by OSIDB Bzimport
Modified: 2026-07-18 08:28 UTC (History)
143 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-06-22 16:02:48 UTC
node-tar is a full-featured Tar for Node.js. Prior to 7.5.16, 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 and extractor disagree on archive contents (e.g. a malware/secret scanner that lists entries with one library while a downstream step extracts with another) This vulnerability is fixed in 7.5.16.


Note You need to log in before you can comment on or make changes to this bug.