What is the CVSS score of EUVD-2026-13596?

EUVD-2026-13596 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of Tar Rs are affected by EUVD-2026-13596?

Organizations using tar-rs face notable risk from CVE-2026-33055 rated CVSS 8.1. Successful exploitation could significantly impact the confidentiality, integrity, or availability of affected…. A patch is available.

How to fix or mitigate EUVD-2026-13596?

Within 7 days: Identify all affected systems and apply vendor patches promptly. Monitor vendor channels for patch availability.

Tar Rs EUVD-2026-13596

| CVE-2026-33055 HIGH

Access of Resource Using Incompatible Type (Type Confusion) (CWE-843)

2026-03-20 security-advisories@github.com

GHSA-gchp-q4r4-x4ff

Information Disclosure Memory Corruption Tar Rs

8.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.1 HIGH

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Ubuntu

MEDIUM

qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch released

Mar 31, 2026 - 21:13 nvd

Patch available

EUVD ID Assigned

Mar 20, 2026 - 08:37 euvd

EUVD-2026-13596

Analysis Generated

Mar 20, 2026 - 08:37 vuln.today

CVE Published

Mar 20, 2026 - 07:16 nvd

HIGH 8.1

DescriptionGitHub Advisory

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.

AnalysisAI

The tar-rs Rust library versions 0.4.44 and below contain a logic flaw where PAX (POSIX.1-2001) size headers are conditionally skipped when the base tar header size is nonzero, causing the library to parse tar archives differently than other standard tar implementations like Go's archive/tar. This discrepancy allows an attacker to craft malicious tar archives that appear different when unpacked by tar-rs versus other parsers, potentially leading to information disclosure or file confusion attacks. The vulnerability affects any application using tar-rs to parse untrusted archives and expecting consistent behavior with other tar parsers, with a moderate CVSS score of 5.1 indicating low attack complexity and network accessibility.

Technical ContextAI

The tar-rs crate is a Rust library for reading and writing tar archives, a widely-used format for bundling multiple files. The vulnerability is rooted in CWE-843 (Access Control - Improper Verification of Data Consistency), where the library's conditional logic in header parsing fails to unconditionally honor PAX size overrides as specified in the POSIX standard. The PAX (Portable Archive Exchange) format allows extended headers to override file sizes specified in the traditional tar header; most tar implementations (including GNU tar, BSD tar, and Go's archive/tar) unconditionally trust PAX size values when present. However, tar-rs only applies the PAX size override when the base header size field is zero, creating a parser discrepancy. This is the inverse of CVE-2025-62518, where astral-tokio-tar had the opposite problem. When a tar archive contains a nonzero base header size alongside a different PAX size header, tar-rs will use the base header size while conforming implementations use the PAX value, leading to divergent unpacking behavior.

RemediationAI

Immediately upgrade the tar-rs crate to version 0.4.45 or later by updating Cargo.toml and running cargo update. For projects with transitive dependencies on tar-rs, run cargo tree to identify all dependents and check upstream projects for updated releases incorporating the patched tar-rs version. Until upgrades are feasible, restrict tar archive processing to trusted sources only and perform additional file integrity validation using independent parsing methods or comparison with reference implementations. Consider implementing a secondary validation step that cross-checks archive contents parsed by tar-rs against outputs from a standards-compliant tar implementation (such as system tar or Go's archive/tar) when processing security-sensitive archives. Refer to the upstream security advisory at https://github.com/alexcrichton/tar-rs/security/advisories/GHSA-gchp-q4r4-x4ff for additional context and the fix details at https://github.com/alexcrichton/tar-rs/commit/de1a5870e603758f430073688691165f21a33946.