Passing this file to our vulnerable-extract app yields:

While running our OS provided tar ((GNU tar) 1.35 in this case) utilitary yields:

Note that it sees the size of the file is 1024

Alternatively using astral-tokio-tar 0.5.6 instead of the abandoned tokio-tar 0.3.1 correctly extract the archive.

Writeup

CVE-2025-62518 (TARmageddon) is a security vulnerability found in the tokio-tar Rust library (Rust vulnerability 😮). This is a logic error in how the headers of the tar format are parsed, allowing an attacker to smuggle files.

The flaw exists in the logic handling PAX Extended Headers. In a TAR archive, there are different header types:

• USTAR: The standard header containing filename, permissions, and size.
• PAX (Type x): An extension header used to provide metadata (like a very large file size) for the next file in the archive.

When a PAX header is present, a parser must resolve the file's actual size by prioritizing the PAX metadata over the standard USTAR header.

But WHY are there 2 types of headers that have priorities for what looks like the same thing? Because the TAR format is old (standardized in 1988), and USTAR has it limitations (size up to 8GB, filename up to 256 characters). That's a problem so PAX header was added in 2001 to allow bigger files and longer filenames.

In vulnerable versions of tokio-tar, the parser correctly adopts the size from the PAX header for the file content reader, but it incorrectly uses the size from the USTAR header to determine where the next file header begins.

The core of the issue is a pointer mismatch. When the vulnerable library processes a file, it uses two different internal "heads" to read the stream:

1. The Content Head: Responsible for reading the actual bytes of the file and writing them to disk.
2. The Parser Head: Responsible for skipping over file data to find the next file header.

In a normal archive, these two heads agree. In TARmageddon, we force them to disagree. By setting the PAX size to 1024 and the USTAR size to 0, we create a paradox:

• The Content Head reads 1024 bytes and puts them into benign_file.txt.
• The Parser Head sees the 0 in the USTAR header and thinks, "I'm already at the end of the file." It stays exactly where it is.

Consequently, the Parser Head treats the data inside the 1024-byte block as the next set of instructions. If that data looks like a valid TAR header, the library will "discover" and extract a second file that technically doesn't exist according to the archive's global structure.

The Smuggling Payload:

The payload is crafted as a sequence of 512-byte blocks. Here is the layout used in the malicious-payload generator:

Because standard tools (like GNU tar) follow the PAX size correctly, they see Block 4 and 5 as harmless binary data belonging to benign_file.txt. They never "execute" the header in Block 4.

How is this a vulnerability, and a CVSS 8.1?

How can this crate having a vulnerability be exploited, why does a file being smuggled in an archive matter?

Supply Chain Injection:

An attacker smuggles malicious files into a build system. Extracting this either for development or on a CI machine, can overwrite legitimate build files, compromising that machine and even tricking the build system to sign malicious files.

Security Bypass (WAF/AV):

A scanner inspects an .tar, scanning it only in the correct mode, undesired files might be present at extraction but were not scanned

Inspired by this writeup