Vulnerability discovered in Rust library for tar archives
The async-tar library and its forks contain a vulnerability named TARmageddon. The most widely used fork tokio-tar will not receive a patch.
(Image: Andrii Yalanskyi/Shutterstock.com)
The Rust library async-tar contains a vulnerability that allows attackers to inject hidden content into tar archives.
Edera, a company specializing in secure runtime environments, has published the bug and given it the somewhat dramatic name TARmageddon. The company maintained its own fork of the library, which has now been archived but is still receiving a patch.
The async-tar library is used for reading and writing tar archives asynchronously. It is significantly more performant than the synchronously operating tar library for Rust.
The associated CVE entry (Common Vulnerabilities and Exposures) CVE-2025-62518 has a severity rating of "high" with a score of 8.1 out of 10.
Fork without Patch: Time to Switch
Even though the CVE entry refers to the astral-tokio-tar library, the vulnerability affects the async-tar library and its forks. The most widely used fork tokio-tar, with over 7 million downloads on the Rust package manager on crates.io has not been maintained for two years. This means it remains vulnerable.
Those using tokio-tar should switch to the astral-tokio-tar fork or another alternative such as the non-asynchronous tar library. The astral-tokio-tar fork has received an update with version 0.5.6 has received an update that fixes the vulnerability.
Confusion in Headers
The bug lies in the processing of headers for tar files. async-tar processes both the ustar and PAX formats. If a file contains headers for both formats, an inconsistency arises: the parser uses the size specified in the ustar header, while other tar tools use the PAX values.
Videos by heise
If the PAX header specifies the correct file size, but ustar is specified with size 0, the parser does not advance but processes the content of nested archives, which other tar tools do not recognize as such and therefore do not inspect.
The blog post about the vulnerability demonstrates this in the following short example:
Expected by scanner/validator:
Entry 1: "outer-file.txt"
Entry 2: "inner-tar-file.tar" (0 bytes per ustar, but N bytes in PAX)
Entry 3: "next-file.txt"
Actually extracted by tokio-tar:
Entry 1: "outer-file.txt"
Entry 2: "inner-tar-file.tar" (0 bytes per ustar)
Entry 3: "inner-file1.txt" (from inner TAR)
Entry 4: "inner-file2.txt" (from inner TAR)
Entry 5: "next-file.txt" (continues normally)The async-tar parser processes the nested files as regular archive contents.
As a theoretical attack scenario, the post the Python package manager uv points out, which, like the now-patched astral-tokio-tar fork, also originates from Astral. Before the patch of the library used in uv, attackers could have smuggled hidden malicious code via a nested tar archive.
Stable Patches
Edera discovered the bug two months ago. The team then created a patch and informed the library maintainers. The libraries astral-tokio-tar and krata-tokio-tar have received the patch, and the maintainer of async-tar has fixed the bug themselves. However, versions on the package manager crates.io for async-tar and krata-tokio-tar, about a year old, are still available without the patch.
The reason the bug is only being published now is due to the 60-day embargo period after Edera reported the bug to the maintainers.
(rme)
