CVE-2026-33056

What it actually does

The flaw is a symlink-following path traversal issue in the Rust tar crate when unpacking archives with unpack_dir in versions 0.4.44 and earlier. During extraction, the library checks an existing path with fs::metadata(), which follows symbolic links. A crafted archive can first create a symbolic link inside the extraction root, then include a directory entry with the same name. The library incorrectly treats the symlink target as an existing directory and may apply chmod to that target, allowing permission changes on directories outside the intended extraction directory. The direct impact is unauthorized modification of filesystem permissions; it does not by itself provide arbitrary file write, code execution, or data disclosure, but it can weaken protections on sensitive directories and enable follow-on compromise depending on the calling application and filesystem permissions.

Why it matters to the business

Applications, build systems, package managers, CI/CD tooling, backup/restore workflows, artifact scanners, or ingestion services that unpack untrusted tar archives using affected tar crate versions may allow an attacker to alter permissions on directories outside the intended extraction area. In practical terms, this could weaken file protections, disrupt operations, or create conditions for later tampering or privilege escalation. The CVSS score is moderate and EPSS is currently low and flat, with no known KEV listing or reported ransomware use, but the issue is still important for software supply-chain and archive-processing systems because tar handling is commonly embedded in downstream Rust applications.

How an attack unfolds

An attacker needs a victim workflow that processes a tar archive they can influence, such as uploaded archives, dependency packages, build artifacts, restore bundles, or extracted attachments. The attacker prepares an archive containing a symbolic link entry within the extraction destination that points to a directory outside that destination. The archive then contains a directory entry using the same path as the symlink. When an affected version of the tar crate extracts the archive through unpack_dir, it checks the already-existing path with fs::metadata(), follows the symlink, and concludes that the target is a valid existing directory. The extraction logic then applies directory permissions to the symlink target rather than only to a directory inside the extraction root. If the process has sufficient filesystem rights, permissions on an external directory are changed, potentially making sensitive locations writable, readable, or executable in ways the system did not intend. Follow-on impact depends on which directory is targeted and what privileges the extracting process has.

How to fix it

Upgrade the Rust tar crate to version 0.4.45 or later wherever it is used directly or transitively. Regenerate lockfiles and rebuild/redeploy affected applications so the patched crate is actually included in shipped artifacts. If immediate upgrade is not possible, avoid extracting untrusted tar archives, run extraction in a sandbox or isolated container with a dedicated low-privilege user, extract only into disposable directories, and prevent the extraction process from having write or chmod capability over sensitive filesystem locations. As a defense-in-depth measure, validate archives before extraction and reject archives containing symbolic links, hard links, absolute paths, parent-directory traversal components, or duplicate path entries when those features are not explicitly required. Do not rely only on post-extraction cleanup, because the permission change occurs during extraction.

How to confirm the fix worked

Confirm dependency versions with cargo tree, cargo metadata, cargo audit, cargo deny, or an equivalent software composition analysis tool, and verify that no built artifact still includes tar crate versions 0.4.44 or earlier. Review Cargo.lock and transitive dependency graphs for package name tar at version 0.4.45 or later. In runtime validation, test archive-ingestion workflows in a non-production environment with a benign archive that contains a symlink followed by a same-name directory entry and confirm that extraction does not modify permissions outside the extraction root. Verify that extraction runs under a constrained service account and that sensitive directories are not writable or chmod-able by that account. For containerized workloads, confirm the image was rebuilt after dependency update rather than only updating source manifests.

Typical attack path

1. Identify an application or automation workflow that accepts or retrieves tar archives from an untrusted or semi-trusted source.
2. Confirm the workflow uses the Rust tar crate version 0.4.44 or earlier and extracts archives with unpack_dir or affected code paths.
3. Create a tar archive containing a symlink entry inside the extraction root that points to a directory outside the extraction root.
4. Add a later directory entry in the archive with the same path as the symlink and attacker-chosen permissions.
5. Deliver the archive through the application’s normal ingestion path, such as upload, dependency retrieval, artifact import, backup restore, or CI/CD processing.
6. Wait for the vulnerable extraction routine to process the archive and apply chmod to the symlink target outside the extraction root.
7. Use the changed permissions for follow-on activity, such as modifying files in a now-writable directory, weakening access controls, or disrupting application behavior.

How to detect it

To assess prior exploitation, focus on systems and workflows that extracted tar archives from untrusted sources using affected tar crate versions. Review application logs for archive uploads, artifact imports, package ingestion, CI/CD job inputs, backup restores, or extraction failures shortly before unexpected permission changes. Correlate extraction timestamps with filesystem audit logs showing chmod, fchmod, fchmodat, or equivalent permission changes on directories outside expected extraction roots. On Linux, auditd, eBPF telemetry, EDR file-event logs, container runtime logs, and CI/CD runner logs are useful sources. Look for chmod operations performed by archive-processing services, build workers, web application processes, package scanners, or restore jobs against directories they normally should not modify. Inspect suspicious archives, if retained, for symlink entries followed later by directory entries using the same path, especially where the symlink target is absolute or escapes the extraction root. Also review directory permission drift on sensitive paths, such as application directories, configuration directories, web roots, shared artifact caches, or deployment locations. No named threat actors, ransomware campaigns, or KEV exploitation are currently associated with this issue based on the provided data.

What your security team should do

• Inventory Rust applications, internal tools, CI/CD jobs, artifact processors, scanners, backup/restore utilities, and services that unpack tar archives.
• Prioritize remediation for internet-facing upload services, automated build systems, package ingestion pipelines, and any process that extracts archives supplied by users or third parties.
• Upgrade the tar crate to 0.4.45 or later, regenerate lockfiles, rebuild artifacts, and redeploy affected services.
• Add CI checks using cargo audit, cargo deny, or SCA tooling to block tar crate versions 0.4.44 and earlier.
• Where archive extraction is required, enforce sandboxing, least privilege, isolated temporary extraction directories, and rejection of unsafe archive entries such as symlinks and duplicate paths unless strictly needed.
• Review recent archive-processing logs and filesystem metadata for unexpected permission changes around the time untrusted archives were extracted.
• Because EPSS is low, there is no KEV listing, and no public exploit maturity is reported, treat this as a targeted remediation priority rather than an emergency patch, unless the affected component processes untrusted archives automatically or with elevated filesystem permissions.