This vulnerability impacts major, widely-used projects, including uv (Astral's lightning-fast Python package manager), testcontainers, and wasmCloud. Due to the widespread nature of tokio-tar in various forms, it is not possible to truly quantify upfront the blast radius of this bug across the ecosystem.
While the active forks have been successfully patched (see also Astral Security Advisory), this disclosure highlights a major systemic challenge: the highly downloaded tokio-tar remains unpatched.
Our suggested remediation is to immediately upgrade to one of the patched versions or remove this dependency. If you depend on tokio-tar, consider migrating to an actively maintained fork like astral-tokio-tar. In addition, the Edera fork krata-tokio-tar will be archived to coalesce all efforts with the astral fork and reduce the ecosystem confusion.
The Challenge of Abandonware: A Decentralized Responsible Disclosure
This vulnerability disclosure was uniquely challenging because the most popular fork (tokio-tar, with over 5 million downloads on crates.io) appears to be abandonware – no longer actively maintained.
In a standard disclosure, a single patch is applied to the main upstream repository, and all downstream users inherit the fix. Because we could not rely on the original project maintainers to apply the fix, we were forced to coordinate a decentralized disclosure across a deep and complex fork lineage:
async-tar (Root) ➡️ tokio-tar (Most popular fork, abandoned) ➡️ krata-tokio-tar (Originally maintained by Edera, now archived) ➡️ astral-tokio-tar (Actively maintained by Astral)
Instead of a single point of contact, we had to:
- Develop patches for the upstream versions.
- Identify and reach out to the maintainers of the unmaintained upstream repositories (
tokio-tarandasync-tar). Neither project had a SECURITY.md or public contact method, so it required some social engineering and community sleuthing to locate the right maintainers. - Individually contact the maintainers of the two most active forks (
astral-tokio-tarandkrata-tokio-tar) and coordinate simultaneous patching under a strict 60-day embargo. - Proactively reach out to major downstream projects (including
testcontainers,binstalk-downloader,liboxen, andopa-wasm) to ensure they were ready to upgrade immediately upon disclosure.
This process required significantly more effort and time than a typical disclosure, underscoring the severe challenges and inefficiency of ensuring wide-scale patching when critical vulnerabilities are found in popular, yet abandoned, open-source dependencies.
Downstream Project Coordination Results
- Binstalk: Plan to eliminate dependency or switch to patched
astral-tokio-tardue to small attack surface. - Opa-wasm: Not affected, as they do not use the vulnerable unpacking/extraction-to-path functionality.
- Other projects were made aware of the upcoming patch and have not responded to our attempts at outreach. Furthermore, there are likely several downstream projects relying on impacted versions that we are not aware of.
Technical Overview & Analysis
This vulnerability is a desynchronization flaw that allows an attacker to "smuggle" additional archive entries into TAR extractions. It occurs when processing nested TAR files that exhibit a specific mismatch between their PAX extended headers and ustar headers.
The flaw stems from the parser's inconsistent logic when determining file data boundaries:
- A file entry has both PAX and ustar headers.
- The PAX header correctly specifies the actual file size (
size=X, e.g., 1MB). - The ustar header incorrectly specifies zero size (
size=0). - The vulnerable
tokio-tarparser incorrectly advances the stream position based on the ustar size (0 bytes) instead of the PAX size (X bytes).
By advancing 0 bytes, the parser fails to skip over the actual file data (which is a nested TAR archive) and immediately encounters the next valid TAR header located at the start of the nested archive. It then incorrectly interprets the inner archive's headers as legitimate entries belonging to the outer archive.
This leads to:
- File overwriting attacks within extraction directories.
- Supply chain attacks via build system and package manager exploitation.
- Bill-of-materials (BOM) bypass for security scanning.
The Parser Misalignment
Normal TAR processing:
Vulnerable Processing (PAX size=X, ustar size=0):
The result seen by the parser:
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 key insight is that the parser's internal position in the stream becomes misaligned, causing it to treat headers and data from a hidden, nested archive as part of the primary archive's entry list.
Attack Scenarios
1. Python Build Backend Hijacking
Target: Python package managers using tokio-tar (e.g., uv). An attacker uploads a malicious package to PyPI. The package's outer TAR contains a legitimate pyproject.toml, but the hidden inner TAR contains a malicious one that hijacks the build backend. During package installation, the malicious config overwrites the legitimate one, leading to RCE on developer machines and CI systems.
2. Container Image Poisoning
Target: Container testing frameworks (e.g., testcontainers). Testing frameworks that extract image layers for analysis can be tricked into processing layers crafted with this nested TAR structure. The hidden inner TAR introduces unexpected or overwritten files, allowing for test environment compromise and supply chain pollution.
3. BOM/Manifest Bypass
Target: Any system with separate "scan/approve" vs "extract/deploy" phases. A security scanner analyzes the outer, clean TAR and approves its limited file set. However, the extraction process using the vulnerable library pulls in additional, unapproved, and unscanned files from the inner TAR, resulting in a security control bypass and policy violation.
Remediation
The Edera team provided patches for astral-tokio-tar (used by uv) and krata-tokio-tar. The vulnerability is tracked as CVE-2025-62518. Huge thank you to the security team at Astral for diligently working with us to patch this vulnerability and responsibly disclose.
The patch requires modifying the TAR parser to:
- Prioritize PAX headers for size determination over ustar headers.
- Validate header consistency between PAX and ustar records.
- Implement strict boundary checking to prevent data/header confusion.
Patches are available here: https://github.com/edera-dev/cve-tarmageddon/tree/main/patches
Due to architectural differences, we did not provide a direct patch for async-tar, but a patch was written by the maintainer.
Alternatives
If immediate patching or switching to a maintained fork is not possible, consider these workarounds:
Alternative Library: The standard tar crate (non-async) correctly handles this scenario and can serve as a temporary replacement:
- Pros: Mature, well-tested, handles PAX headers correctly
- Cons: Synchronous API only, may require architectural changes for async codebases
- Migration: Consider wrapping tar operations in tokio::task::spawn_blocking() for async compatibility
Runtime Mitigations:
- Validate extracted file counts against expected manifests
- Implement post-extraction directory scanning to detect unexpected files
- Use separate extraction sandboxes with file count/size limits
- Disable file overwriting during extraction where possible.
A Note on Rust, Security Boundaries, and the Path Forward
The discovery of TARmageddon is an important reminder that Rust is not a silver bullet. While Rust's guarantees make it significantly harder to introduce memory safety bugs (like buffer overflows or use-after-free), it does not eliminate logic bugs—and this parsing inconsistency is fundamentally a logic flaw. Developers must remain vigilant against all classes of vulnerabilities, regardless of the language used.
This lineage of vulnerable libraries (async-tar ➡️ tokio-tar ➡️ forks) tells a common open-source story: popular code, even in modern secure languages, can become unmaintained and expose its millions of downstream users to risk.
This experience reinforces the importance of defense-in-depth. We are happy to report that due to proactive design in Edera, our own products were not vulnerable to this bug despite embedding the vulnerable krata-tokio-tar. By implementing strong security boundaries and ensuring that vulnerable operations were not used in critical pathways, Edera mitigated the issue before the patch was even released.
Lastly, we’d like to thank the researchers and maintainers across the ecosystem that worked with us to responsibly disclose and patch this vulnerability.
Timeline – 60 Day Disclosure Embargo
8/21: Bug discovered.
8/21: Initial investigation found the vulnerability in krata-tokio-tar and astral-tokio-tar, as well as the upstream tokio-tar and async-tar
8/21: Minimal reproduction created
8/22: Created patches for all libraries
8/22: Disclosed bug to maintainers of all libraries, the rust foundation, and select downstream projects (selected by number of downloads). The embargo date was set to October 21.
8/22: Received response from astral-tokio-tar and tokio-tar and shared the patch
9/2: Received acknowledgment from async-tar
10/21: Publish GHSA and patches for astral-tokio-tar and krata-tokio-tar