Listen to this Post
In versions 0.5.6 and earlier of the `astral-tokio-tar` library, a critical flaw exists in how PAX extended headers are processed. The vulnerability arises when a tar archive contains a PAX extended header that overrides a file’s size, while the corresponding ustar header retains a different value, often zero. The vulnerable parser incorrectly uses the ustar header’s size (zero) to calculate the offset for the next file entry in the archive. Consequently, the parser does not advance its read position, causing the file content that follows to be misinterpreted as a series of new, legitimate tar headers. This allows an attacker to smuggle malicious entries into the archive that are extracted by a secondary, stricter parser, leading to a parser differential attack. This can result in arbitrary file writes during extraction, potentially leading to code execution or credential exfiltration. The issue is resolved in version 0.6.0 by rejecting malformed PAX extensions entirely.
dailycve form:
Platform: astral-tokio-tar
Version: 0.5.6 and earlier
Vulnerability: PAX Header Desynchronization
Severity: HIGH
date: 2025-10-21
Prediction: include expected Patch date. Patched in 0.6.0
What Undercode Say:
Analytics:
This vulnerability (CVE-2025-62518) is classified under CWE-843 (Type Confusion) . It has a CVSS score of 8.1, with a vector of AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N . The attack complexity is low, requires user interaction, and can lead to high confidentiality and integrity impact. While the general severity is HIGH, its impact on specific downstream projects like `uv` is considered LOW because those projects already handle untrusted code execution as part of their design .
Exploit:
The exploit leverages a tar archive with mismatched headers.
// Vulnerable code snippet from astral-tokio-tar (pre-0.5.6) // The position is advanced based on the ustar header size, ignoring the PAX override. let file_size = header.size(); // Returns 0 from the manipulated ustar field let next_pos = current_pos + 512 + pad_to_512(file_size); // Advances by 0 bytes, causing desync
An attacker crafts a tar file where a PAX header specifies a large size, but the ustar header says 0. The vulnerable parser skips 0 bytes, and the subsequent data (which is actually the content of the first file) is parsed as new tar entries, smuggling them past the security controls.
Protection from this CVE:
The primary mitigation is to upgrade to version 0.6.0 or later .
Update the dependency in Cargo.toml
cargo update -p astral-tokio-tar --precise 0.6.0
Or if directly patching, apply the fix which applies PAX overrides before position calculation
// Patched code logic
let mut file_size = header.size();
if let Some(pax_size) = pending_pax.get("size") {
file_size = pax_size.parse().unwrap(); // Use the PAX size
}
let next_pos = current_pos + 512 + pad_to_512(file_size); // Correctly advances
There are no workarounds other than upgrading .
Impact:
Successful exploitation allows an attacker to perform a parser differential attack. By smuggling entries, they can bypass the intended extraction logic, leading to arbitrary file writes on the system where the tar archive is extracted. This can be a stepping stone to arbitrary code execution or the exfiltration of sensitive credentials . The impact is context-dependent but can be severe in applications that extract untrusted tar files without further validation.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
