node-tar applies PAX size override to intermediary GNU long-name/long-link headers, causing tar parser interpretation differential (file smuggling)
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.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-53655
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 8 Nov 2026, 02:28 UTC · Revision 1
Source evidence
node-tar applies PAX size override to intermediary GNU long-name/long-link headers, causing tar parser interpretation differential (file smuggling)
core-osv · Original sourcePublished 22 Jun 2026, 14:55 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.
osv:CVE-2026-53655
Complete source record
{
"id": "bc2f9cce0f01c3224ccf8772b3d437ec4b96390ff7ae8520550a2badb72dcdc6",
"url": "https://osv.dev/vulnerability/CVE-2026-53655",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "node-tar applies PAX size override to intermediary GNU long-name/long-link headers, causing tar parser interpretation differential (file smuggling)",
"summary": "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.",
"evidence": "osv:CVE-2026-53655",
"products": [],
"severity": "medium",
"structured": {
"id": "CVE-2026-53655",
"aliases": [
"CVE-2026-53655",
"GHSA-vmf3-w455-68vh"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/isaacs/node-tar",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "cf213384ac558b539c07c830ed7cca5ffc9e8550"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "0"
},
{
"fixed": "7.5.16"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"cpe": "cpe:2.3:a:isaacs:tar:*:*:*:*:*:node.js:*:*",
"range": [
{
"introduced": "0"
},
{
"fixed": "7.5.16"
}
],
"source": "CPE_RANGE"
}
]
}
}
],
"versions": [
"v7.5.15",
"v7.5.14",
"v7.5.13",
"v7.5.12",
"v7.5.11",
"v7.5.10",
"v7.5.9",
"v7.5.8",
"v7.5.7",
"v7.5.6",
"v7.5.5",
"v7.5.4",
"v7.5.3",
"v7.5.2",
"v7.5.1",
"v7.5.0",
"v7.4.4",
"v7.4.3",
"v7.4.2",
"v7.4.1",
"v7.4.0",
"v7.3.0",
"v7.2.0",
"v7.1.0",
"v7.0.1",
"v7.0.0",
"v6.2.1",
"v6.2.0",
"v6.1.15",
"v6.1.14",
"v6.1.13",
"v6.1.12",
"v6.1.11",
"v6.1.10",
"v6.1.9",
"v6.1.8",
"v6.1.7",
"v6.1.6",
"v6.1.5",
"v6.1.4",
"v6.1.3",
"v6.1.2",
"v6.1.1",
"v4.4.13",
"v5.0.5",
"v6.1.0",
"v6.0.5",
"v6.0.4",
"v6.0.3",
"v6.0.2",
"v6.0.1",
"v6.0.0",
"v5.0.2",
"v5.0.4",
"v5.0.3",
"v5.0.1",
"v4.4.12",
"v4.4.11",
"v4.4.10",
"v4.4.9",
"v2.2.1",
"v4.4.8",
"v4.4.7",
"v4.4.6",
"v4.4.5",
"v4.4.4",
"v4.4.3",
"v4.4.2",
"v4.4.1",
"v4.4.0",
"v4.3.3",
"v4.3.2",
"v4.3.1",
"v4.3.0",
"v4.2.0",
"v4.1.2",
"v4.1.1",
"v4.1.0",
"v4.0.2",
"v4.0.1",
"v3.2.0",
"v4.0.0",
"v3.1.15",
"v3.1.14",
"v3.1.13",
"v3.1.12",
"v3.1.11",
"v3.1.10",
"v3.1.9",
"v3.1.8",
"v3.1.7",
"v3.1.6",
"v3.1.5",
"v3.1.4",
"v3.1.3",
"v3.1.2",
"v3.1.1",
"v3.1.0",
"v3.0.1",
"v3.0.0",
"v2.1.1",
"v2.1.0",
"v2.0.1",
"v2.0.0",
"v1.0.3",
"v1.0.2",
"v1.0.1",
"v1.0.0",
"v0.1.20",
"v0.1.19",
"v0.1.18",
"v0.1.17",
"v0.1.16",
"v0.1.15",
"v0.1.14",
"0.1.13",
"0.1.12",
"0.1.11",
"0.1.10",
"0.1.9",
"0.1.8",
"0.1.7",
"0.1.6",
"0.1.5",
"0.1.3",
"0.1.2",
"0.1.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-53655.json"
}
}
],
"modified": "2026-10-28T02:30:52.759359529Z",
"provider": "osv",
"references": [
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53655.json",
"https://github.com/isaacs/node-tar/security/advisories/GHSA-vmf3-w455-68vh",
"https://nvd.nist.gov/vuln/detail/CVE-2026-53655"
],
"provider_metadata": {
"cwe_ids": [
"CWE-436"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53655.json"
}
},
"related_cves": [
{
"value": "CVE-2026-53655",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 521789,
"published_at": "2026-06-22T14:55:50.133+00:00"
}