CVE-2026-33055

What it actually does

tar-rs versions 0.4.44 and earlier incorrectly handle tar entries that contain both a nonzero base header size and a PAX extended header size override. In this condition, tar-rs skips the PAX size value while most other tar parsers honor it. An attacker can craft a tar archive that is interpreted differently by tar-rs versus other tooling, creating parser differential behavior. The main technical risk is archive smuggling: security scanners, validators, indexers, or policy checks may see one file layout or file content while another extraction or processing component sees something different.

Why it matters to the business

Systems that accept or process tar archives may make incorrect trust decisions about uploaded files, software artifacts, backups, source packages, or build inputs. This can lead to hidden or substituted content passing validation, causing supply-chain integrity failures, unsafe files entering build or deployment workflows, or operational confusion during archive handling. The issue is not currently listed in CISA KEV, has no known mature public exploitation, and has a low EPSS score, but affected Rust applications should still upgrade because archive parser inconsistencies are commonly useful for bypassing security controls.

How an attack unfolds

An attacker creates a tar archive containing entries with conflicting file-size metadata: a nonzero size in the normal tar header and a different size in the PAX extended header. The attacker then submits or distributes the archive to a workflow that uses tar-rs for one stage and another tar parser, or assumptions based on another parser, for a different stage. Because vulnerable tar-rs versions ignore the PAX size override in this case, the same archive can appear to contain different file contents or boundaries depending on which parser reads it. If a validation, scanning, allowlist, or metadata extraction step relies on the vulnerable interpretation while a later extraction or consumption step honors the PAX value, prohibited or unexpected content may be smuggled past controls. Exploitation generally requires the target application or a user-driven workflow to process the malicious archive; this is not a direct unauthenticated remote code execution flaw by itself.

How to fix it

Upgrade the Rust tar crate to version 0.4.45 or later wherever it is used directly or transitively. Run dependency resolution updates, rebuild affected applications, and redeploy the rebuilt artifacts. For Cargo-based projects, review Cargo.lock and use commands such as `cargo update -p tar --precise 0.4.45` where appropriate, or update dependent crates that pin vulnerable tar versions. Also review archive-processing workflows for parser consistency: use the same parser for validation and extraction where possible, reject archives with conflicting PAX and base header metadata, treat tar archives as untrusted input, and process them in sandboxed or least-privilege environments.

How to confirm the fix worked

Confirm that no deployed build, container image, binary, or SBOM references tar-rs versions 0.4.44 or earlier. Check `Cargo.lock`, generated SBOMs, dependency scans, and `cargo tree -i tar` output for the resolved tar crate version. Validate that rebuilt applications include tar 0.4.45 or later. Where feasible, run a regression test using a tar archive with mismatched base header and PAX size values and confirm the application either honors the PAX size consistently with modern parsers or rejects the archive. For externally exposed archive upload or ingestion features, verify that controls reject malformed or ambiguous archives and that validation and extraction use consistent parsing behavior.

Typical attack path

1. Identify an application, CI/CD workflow, package ingestion service, backup process, or artifact processor that uses the Rust tar crate version 0.4.44 or earlier.
2. Craft a tar archive with a normal tar header size and a conflicting PAX extended header size for one or more entries.
3. Place benign-looking content where the vulnerable tar-rs interpretation will read it and hidden or alternate content where another parser will read it.
4. Submit the archive through an upload, package publication, source import, build artifact, backup restore, or other archive-processing path.
5. Rely on parser disagreement so validation, scanning, indexing, or policy checks see different content than the component that later extracts or consumes the archive.
6. Use the resulting mismatch to bypass controls, introduce unexpected files or data, or cause downstream processing to operate on attacker-controlled content.

How to detect it

To assess possible prior exploitation, focus on places where untrusted tar archives were accepted or processed before the upgrade. Review application logs, upload logs, artifact repository logs, CI/CD job logs, package ingestion logs, backup restore logs, and security scanner logs for archives that produced inconsistent file counts, unexpected end-of-file errors, checksum mismatches, policy scan/extraction discrepancies, or parser warnings involving PAX headers. Preserve and reanalyze suspicious archives with multiple parsers, including a fixed tar-rs version and another common parser such as GNU tar, bsdtar, or Go archive/tar, then compare file names, sizes, checksums, and extracted byte ranges. Look for cases where a validation step accepted an archive but a later extraction step produced additional, truncated, shifted, or different content. There are no known public threat actors or ransomware campaigns tied to this issue, so detection should be behavior-based rather than actor-based.

• Cargo.lock
• name = "tar"
• version = "0.4.44"
• version = "0.4.43"
• version = "0.4.42"
• tar = "0.4.44"
• tar = "0.4.43"
• tar = "0.4.42"
• pax_global_header
• PaxHeaders
• size=

What your security team should do

• Inventory applications, services, build tools, and ingestion pipelines that process tar, tar.gz, tgz, or source package archives using Rust dependencies.
• Prioritize remediation for internet-facing upload services, package registries, CI/CD systems, artifact scanners, source importers, backup restore workflows, and any security control that validates archives before extraction.
• Upgrade all direct and transitive uses of the tar crate to 0.4.45 or later, then rebuild and redeploy affected software.
• Add archive parser differential tests to security regression suites, especially for PAX headers, long path metadata, links, and file-size overrides.
• Align validation and extraction logic so the same parser and security policy are applied throughout the workflow.
• Temporarily reject or quarantine tar archives containing conflicting PAX `size` metadata until all affected components are upgraded.
• Review recently processed untrusted archives for suspicious parser errors, inconsistent extracted output, or policy-bypass anomalies.
• Monitor vulnerability feeds for downstream advisories in products that bundle tar-rs, because many organizations may consume the library indirectly.