CVE-2025-62518 Shows the Cost of Open Source Abandonware

TARmageddon (CVE-2025-62518): RCE Vulnerability Highlights the Challenges of Open Source Abandonware

October 21, 2025
Alex Zenla

The Edera team has uncovered a critical boundary-parsing bug, dubbed TARmageddon ( CVE-2025-62518), in the popular async-tar Rust library and its deep lineage of forks, including the widely used tokio-tar. In the worst-case scenario, this vulnerability has a severity of 8.1 (High) and can lead to Remote Code Execution (RCE) through file overwriting attacks, such as replacing configuration files or hijacking build backends.

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:

  1. Develop patches for the upstream versions.
  2. Identify and reach out to the maintainers of the unmaintained upstream repositories (tokio-tar and async-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.
  3. Individually contact the maintainers of the two most active forks (astral-tokio-tar and krata-tokio-tar) and coordinate simultaneous patching under a strict 60-day embargo.
  4. Proactively reach out to major downstream projects (including testcontainers, binstalk-downloader, liboxen, and opa-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

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:

  1. A file entry has both PAX and ustar headers.
  2. The PAX header correctly specifies the actual file size (size=X, e.g., 1MB).
  3. The ustar header incorrectly specifies zero size (size=0).
  4. The vulnerable tokio-tar parser 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:

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:

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:

Runtime Mitigations:

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