tar-rs incorrectly ignores PAX size headers if header size is nonzero
tar-rs is a tar archive reading/writing library for Rust. Versions 0.4.44 and below have conditional logic that skips the PAX size header in cases where the base header size is nonzero. As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue. Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. This issue has been fixed in version 0.4.45.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-33055
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 8 Nov 2026, 03:08 UTC · Revision 1
Source evidence
tar-rs incorrectly ignores PAX size headers if header size is nonzero
core-osv · Original sourcePublished 20 Mar 2026, 07:06 UTC
tar-rs is a tar archive reading/writing library for Rust. Versions 0.4.44 and below have conditional logic that skips the PAX size header in cases where the base header size is nonzero. As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue. Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. This issue has been fixed in version 0.4.45.
osv:CVE-2026-33055
Complete source record
{
"id": "b004be7da8105199bb8b864b9f52f1ebf67f86441e1eb1b60065059b4cc48d4c",
"url": "https://osv.dev/vulnerability/CVE-2026-33055",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "tar-rs incorrectly ignores PAX size headers if header size is nonzero",
"summary": "tar-rs is a tar archive reading/writing library for Rust. Versions 0.4.44 and below have conditional logic that skips the PAX size header in cases where the base header size is nonzero. As part of CVE-2025-62518, the astral-tokio-tar project was changed to correctly honor PAX size headers in the case where it was different from the base header. This is almost the inverse of the astral-tokio-tar issue. Any discrepancy in how tar parsers honor file size can be used to create archives that appear differently when unpacked by different archivers. In this case, the tar-rs (Rust tar) crate is an outlier in checking for the header size - other tar parsers (including e.g. Go archive/tar) unconditionally use the PAX size override. This can affect anything that uses the tar crate to parse archives and expects to have a consistent view with other parsers. This issue has been fixed in version 0.4.45.",
"evidence": "osv:CVE-2026-33055",
"products": [],
"severity": "medium",
"structured": {
"id": "CVE-2026-33055",
"aliases": [
"CVE-2026-33055",
"GHSA-gchp-q4r4-x4ff",
"RUSTSEC-2026-0068"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/composefs/tar-rs",
"type": "GIT",
"events": [
{
"introduced": "0"
},
{
"fixed": "096e3d16d14fefac51bc4d94d616b21546ea8bcc"
},
{
"fixed": "de1a5870e603758f430073688691165f21a33946"
}
],
"database_specific": {
"extracted_events": [
{
"cpe": "cpe:2.3:a:alexcrichton:tar-rs:*:*:*:*:*:rust:*:*",
"range": [
{
"introduced": "0"
},
{
"fixed": "0.4.45"
}
],
"source": "CPE_RANGE"
},
{
"range": [
{
"fixed": "de1a5870e603758f430073688691165f21a33946"
}
],
"source": "REFERENCES_COMMIT"
}
]
}
}
],
"versions": [
"0.4.44",
"0.4.43",
"0.4.42",
"0.4.41",
"0.4.40",
"0.4.39",
"0.4.38",
"0.4.37",
"0.4.36",
"0.4.35",
"0.4.34",
"0.4.33",
"0.4.32",
"0.4.31",
"0.4.30",
"0.4.29",
"0.4.28",
"0.4.27",
"0.4.26",
"0.4.25",
"0.4.24",
"0.4.23",
"0.4.22",
"0.4.21",
"0.4.20",
"0.4.19",
"0.4.18",
"0.4.17",
"0.4.16",
"0.4.15",
"0.4.14",
"0.4.13",
"0.4.12",
"0.4.11",
"0.4.10",
"0.4.9",
"0.4.8",
"0.4.7",
"0.4.6",
"0.4.5",
"0.4.4",
"0.4.3",
"0.3.3",
"0.4.2",
"0.4.1",
"v0.4.0",
"0.4.0",
"0.3.2",
"0.3.1",
"0.3.0",
"0.2.14",
"0.2.13",
"0.2.12",
"0.2.11",
"0.2.10",
"0.2.9",
"0.2.8",
"0.2.7",
"0.2.6",
"0.2.5",
"0.2.4",
"0.2.2",
"0.2.1",
"0.1.11",
"0.1.9",
"0.1.8",
"0.1.6",
"0.1.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-33055.json"
}
}
],
"modified": "2026-10-28T02:30:53.433612107Z",
"provider": "osv",
"references": [
"https://www.cve.org/CVERecord?id=CVE-2025-62518",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/33xxx/CVE-2026-33055.json",
"https://github.com/alexcrichton/tar-rs/security/advisories/GHSA-gchp-q4r4-x4ff",
"https://nvd.nist.gov/vuln/detail/CVE-2026-33055",
"https://github.com/alexcrichton/tar-rs/commit/de1a5870e603758f430073688691165f21a33946"
],
"provider_metadata": {
"cwe_ids": [
"CWE-843"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/33xxx/CVE-2026-33055.json"
}
},
"related_cves": [
{
"value": "CVE-2026-33055",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 522079,
"published_at": "2026-03-20T07:06:08.39+00:00"
}