CVE-2025-62518

What it actually does

The flaw is an improper input validation issue in astral-tokio-tar before 0.5.6. A crafted tar archive can use PAX extended headers to override an entry size while the vulnerable parser advances through the stream using the original ustar header size, often zero. This desynchronizes parsing so bytes that should be treated as file content are instead interpreted as new tar headers, allowing hidden or smuggled archive entries to be processed. In applications that trust archive enumeration for validation, scanning, policy enforcement, or extraction, this can enable unauthorized file creation, content substitution, bypass of archive allowlists, and exposure or modification of sensitive data handled by the application.

Why it matters to the business

Systems that accept or process untrusted tar archives may fail to see the same archive contents during validation and extraction, creating a risk that malicious files bypass security checks and are written or processed later. This can affect software supply chains, upload pipelines, build systems, artifact repositories, backup/restore workflows, and browser or package components that unpack tar content. Although the EPSS score is currently low and the issue is not in CISA KEV or known ransomware use, the CVSS severity is high because exploitation can lead to serious confidentiality and integrity failures when archive ingestion is exposed to external users or automated feeds. The issue has been public for 292 days, so vulnerable dependencies should be treated as overdue for remediation.

How an attack unfolds

An attacker prepares a tar archive containing a PAX extended header that declares a file size different from the size in the legacy ustar header. The archive is arranged so that when vulnerable code advances by the ustar size rather than the PAX-specified size, the parser becomes misaligned and begins reading attacker-controlled file content as if it were the next tar header. The attacker embeds one or more valid-looking tar headers inside that content, effectively smuggling extra archive entries that may not be visible to validation logic relying on the intended entry boundaries. The attacker then delivers the archive to a service, user, CI job, package ingestion process, or other workflow that processes tar files with the vulnerable library. If the application extracts, indexes, signs, scans, or trusts the parsed entries, the smuggled files may be written, accepted, or processed despite policy checks. The named activity label TARmageddon should be considered relevant context for threat hunting where archive-smuggling attempts are suspected, but exploitation should primarily be detected through archive-processing artifacts rather than actor-specific infrastructure.

How to fix it

Upgrade astral-tokio-tar to version 0.5.6 or later wherever it is used directly or transitively. There are no reliable workarounds for the vulnerable parser behavior. Regenerate lockfiles and rebuild/redeploy affected applications so the patched dependency is actually linked into production artifacts. If using OS package metadata from the supplied affected product list, ensure chromium-browser on Ubuntu 14.04 LTS is updated to 65.0.3325.181-0ubuntu0.14.04.1 or later, while separately verifying whether any Rust components embed astral-tokio-tar. Until patching is complete, restrict tar archive ingestion to trusted sources, disable automated extraction of untrusted tar files where feasible, isolate archive-processing workers, and enforce least-privilege write permissions on extraction destinations.

How to confirm the fix worked

Confirm dependency remediation with software composition analysis and build-level checks rather than relying only on source manifests. For Rust projects, inspect Cargo.toml, Cargo.lock, vendored dependencies, and SBOMs for astral-tokio-tar versions below 0.5.6; use tools such as cargo tree, cargo audit, cargo deny, or equivalent SCA tooling. Verify rebuilt binaries or containers were produced after the dependency update and that no older vendored copy remains. For OS packages, validate installed package versions with the platform package manager and confirm chromium-browser is at or above 65.0.3325.181-0ubuntu0.14.04.1 where applicable. In staging, process a regression archive with conflicting PAX and ustar sizes and confirm patched code does not enumerate or extract embedded smuggled entries. Also compare application archive inventories against a trusted tar implementation and confirm the same entries are observed before and after validation/extraction.

Typical attack path

1. Identify an application, service, build pipeline, package processor, or user workflow that accepts tar archives and uses astral-tokio-tar before version 0.5.6.
2. Craft a tar archive with PAX extended headers containing size overrides that conflict with the ustar header size.
3. Place attacker-controlled bytes after the PAX entry so the vulnerable parser interprets embedded content as additional tar headers.
4. Submit the malicious archive through an upload, import, dependency ingestion, artifact processing, backup restore, or user-assisted open action.
5. Rely on parser desynchronization to smuggle additional entries past validation, scanning, filtering, or archive inventory logic.
6. Cause the application to extract, process, publish, trust, or expose the smuggled entries, resulting in confidentiality or integrity impact.

How to detect it

Look for evidence in archive upload logs, application ingestion logs, CI/CD job logs, artifact repository logs, file extraction telemetry, EDR file creation events, and object storage records for tar files processed before patching. Focus on archives containing PAX extended headers where the PAX-declared size differs from the legacy tar header size, especially entries with ustar size zero followed by bytes that resemble tar headers. Review extraction destinations for unexpected files created at the same time as archive processing, files absent from pre-extraction validation inventories, unusual overwrites, or files with names that violate normal application policy. Compare historical stored archives against trusted tar parsers and custom structural analysis to find mismatches between expected entry boundaries and parsed entries. Search application logs for tar parsing errors, unexpected end-of-archive behavior, duplicate file names, inconsistent entry counts, or validation/extraction count mismatches. If TARmageddon-related reporting is tracked internally, correlate suspicious archive submissions with any known campaign timing, source addresses, accounts, or delivery channels, but do not depend on actor attribution for detection.

What your security team should do

• Prioritize inventory for externally reachable archive upload, artifact ingestion, CI/CD, package repository, backup restore, and file-conversion services that process tar files.
• Upgrade all direct and transitive uses of astral-tokio-tar to 0.5.6 or later and redeploy affected applications.
• Treat remediation as overdue because the vulnerability has been public for 292 days, even though EPSS is currently low and it is not listed in CISA KEV.
• Temporarily restrict or disable processing of untrusted tar archives until affected services are patched.
• Harden extraction workflows by running them in sandboxed, low-privilege workers with constrained output directories and no access to sensitive files.
• Add archive-ingestion logging that records original archive hashes, parsed entry names, sizes, PAX metadata presence, extraction paths, and validation outcomes.
• Hunt for historical archive submissions that contain PAX extended headers with conflicting sizes or unexpected additional entries, especially around sensitive build or artifact workflows.
• Review security controls that validate archives before extraction to ensure validation and extraction use the same patched parser and same interpretation rules.