GHSA-3pv8-6f4r-ffg2

What it actually does

The Rust `tar` crate incorrectly handles certain malformed PAX extended headers, creating a parser desynchronization condition when processing tar archives. PAX headers are used to carry extended metadata such as long paths, link targets, ownership, timestamps, and other attributes. If an application parses or extracts attacker-supplied tar archives with an affected version, a crafted archive may cause the library to associate metadata with the wrong entry or interpret archive contents differently than expected. The practical impact depends on how the consuming application uses the crate, but risks include bypassing archive validation logic, extracting unexpected paths or metadata, overwriting files within the extraction scope, or processing archive entries that a pre-extraction scanner did not accurately evaluate.

Why it matters to the business

Systems that accept or process untrusted tar archives may be exposed to supply-chain, build, backup, package-ingestion, or file-upload risks. A malicious archive could cause applications to extract or process files differently than security checks expect, potentially leading to corrupted artifacts, unexpected file writes, broken isolation assumptions, or downstream compromise if extracted content is later executed or trusted. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and is fixed in `tar` crate version `0.4.46`, so remediation should be prioritized for services that ingest archives from users, partners, CI/CD pipelines, package registries, or automated import workflows.

How an attack unfolds

An attacker first identifies an application, service, build pipeline, or automation component that uses a vulnerable version of the Rust `tar` crate to read or extract tar archives. The attacker then crafts a tar file containing malformed or unusual PAX extended headers designed to desynchronize how the crate parses metadata and subsequent archive entries. The archive is delivered through a supported ingestion path, such as a file upload, package import, backup restore, artifact processing job, or CI/CD dependency workflow. When the vulnerable application parses the archive, the parser may apply PAX metadata incorrectly or interpret later records differently than validation logic expects. If the application extracts the archive or trusts the parsed file list, the attacker may cause unexpected files, paths, links, or metadata to be processed, potentially bypassing allowlists, archive scanners, or path validation performed before extraction.

How to fix it

Upgrade the Rust `tar` crate to version `0.4.46` or later. Regenerate lockfiles and rebuild all binaries, containers, serverless artifacts, and packages that statically include the vulnerable dependency. In Rust projects, update `Cargo.toml` and `Cargo.lock`, then verify with `cargo tree -i tar` and dependency scanning tools that no affected version remains. If immediate upgrade is not possible, restrict tar archive processing to trusted sources only, disable extraction of user-supplied tar files where feasible, enforce strict extraction directories, reject archives containing PAX extended headers unless required, block absolute paths and parent-directory traversal, reject symlinks and hardlinks where not needed, and perform validation and extraction using the same hardened parser to avoid scanner/extractor mismatches.

How to confirm the fix worked

Confirm that all applications and build artifacts use `tar` crate `0.4.46` or later. Check `Cargo.lock` for `name = "tar"` and verify the resolved version is at least `0.4.46`. Use `cargo tree -i tar` to identify direct and transitive dependency paths. Run software composition analysis against source repositories, built containers, and released binaries where possible. Validate archive-handling behavior with regression tests using malformed PAX headers, long paths, symlinks, hardlinks, absolute paths, and `../` traversal attempts, ensuring unsafe archives are rejected or extracted only within the intended sandbox. Confirm that CI/CD pipelines and deployment images have been rebuilt after dependency update, not merely patched in source control.

Typical attack path

1. Identify a target workflow that accepts, scans, imports, or extracts tar archives using the Rust `tar` crate.
2. Confirm or infer that the application uses an affected `tar` crate version prior to `0.4.46`.
3. Create a tar archive with crafted PAX extended headers intended to desynchronize archive metadata parsing.
4. Submit the archive through a normal ingestion channel such as upload, package import, artifact submission, backup restore, or CI/CD workflow.
5. Trigger server-side parsing or extraction of the archive by the vulnerable application.
6. Abuse the parsing mismatch to cause unexpected archive entries, paths, links, or metadata to be accepted, extracted, or processed.
7. Leverage any downstream trust boundary, such as execution of extracted files, publication of corrupted artifacts, overwrite of expected files, or bypass of archive validation controls.

How to detect it

To determine whether this was already exploited, review systems that accept or process tar archives, including upload services, artifact repositories, CI/CD workers, package importers, backup restore jobs, and automated file-processing queues. Examine application logs for tar parsing failures, PAX header errors, archive extraction warnings, unexpected path rejection events, symlink or hardlink handling warnings, and discrepancies between pre-extraction archive listings and extracted files. Review file-system audit logs around archive extraction directories for unexpected writes, overwritten files, absolute-path extraction attempts, parent-directory traversal attempts, unusual symlink or hardlink creation, and files appearing outside intended extraction roots. Inspect stored uploaded archives for PAX extended headers and malformed metadata records, especially archives submitted shortly before anomalous processing errors or unexpected output artifacts. Where available, correlate archive submissions with process execution telemetry to determine whether extracted files were later executed, packaged, published, or moved into trusted locations. There are no provided named threat actors, ransomware campaigns, KEV status, or known exploit indicators, so detection should focus on suspicious archive structure and abnormal extraction behavior rather than known attacker infrastructure.

What your security team should do

• Inventory services, tools, build jobs, and ingestion pipelines that process tar archives using Rust components.
• Prioritize remediation for internet-facing upload services, artifact processing systems, package ingestion workflows, CI/CD runners, backup restore tooling, and any workflow that accepts archives from untrusted or semi-trusted parties.
• Upgrade the `tar` crate to `0.4.46` or later and rebuild all dependent artifacts.
• Review archive extraction controls for defense in depth: sandbox extraction, deny absolute paths, deny parent-directory traversal, restrict symlinks and hardlinks, enforce file count and size limits, and scan extracted output before use.
• Add dependency scanning rules to flag `tar` crate versions earlier than `0.4.46`.
• Search logs and artifact stores for suspicious tar submissions containing PAX extended headers, especially where extraction errors, parser warnings, or unexpected file paths were observed.
• If archive ingestion is business-critical, add regression tests covering malformed PAX headers to prevent future parser/scanner mismatch issues.
• Because there is no provided evidence of KEV listing, ransomware use, or mature public exploitation, prioritize based on exposure to untrusted archives rather than broad emergency response.