Most developers thinking about archive extraction security think about path traversal. Zip Slip, the vulnerability class documented by Snyk in 2018, describes archives with entries using paths like ../../.bashrc that write files outside the intended extraction directory. The class is well-understood, and most mature archive libraries have addressed it. The Rust tar crate received its own path traversal fixes years before this advisory.
CVE-2026-33056 is something different. The Rust Security Response Team’s advisory describes a vulnerability in the tar crate, a third-party library used by Cargo to extract packages during a build, that allows a malicious crate to change the permissions on arbitrary directories on the filesystem. The attack doesn’t involve writing files to arbitrary locations; it targets the permission bits of directories that already exist. The distinction between writing files and changing permissions matters more than it might initially seem.
How Cargo Extracts Packages
When you add a dependency to Cargo.toml and run cargo build, Cargo downloads .crate files from the registry. These are gzipped tar archives. Cargo stores them in ~/.cargo/registry/cache/ and extracts them into ~/.cargo/registry/src/ before compilation.
The extraction step delegates to the tar crate, which parses each archive entry, creates the corresponding files and directories, and applies the metadata stored in the archive’s headers. That metadata includes permission bits.
A tar archive entry header stores, among other fields:
name: 100 bytes (the file/directory path)
mode: 8 bytes (octal permission bits, e.g., 0000755)
uid: 8 bytes (numeric user ID)
gid: 8 bytes (numeric group ID)
size: 12 bytes (size in bytes for regular files)
typeflag: 1 byte (file, directory, symlink, hardlink, etc.)
linkname: 100 bytes (symlink target if typeflag is symlink)When extracting, a tar library reads each entry in sequence. For a directory entry, it creates the directory if needed and then calls the platform’s chmod equivalent on the path to apply the stored mode. This is where CVE-2026-33056’s attack surface sits: the code applying permissions must validate that the path it is operating on resolves within the extraction boundary, and it must do so after following any symlinks. A check that works correctly for file creation can fail to account for the way a permission-application call follows a previously extracted symlink to a location outside the extraction directory.
Why Permission Attacks Are Distinct
Path traversal vulnerabilities create or overwrite files at arbitrary locations. Defenses against them focus on rejecting paths that escape the destination, which most scanners and security tools check for explicitly.
Permission manipulation doesn’t create any new files. An archive that exploits CVE-2026-33056 can look like a completely normal crate, with no suspicious file paths, until the moment Cargo applies chmod to a resolved symlink target. The consequences depend on which directory gets targeted and how the permissions are modified:
- A directory like
~/.sshset to mode0777becomes world-writable, allowing any local process to modifyauthorized_keys - A directory set to mode
0000becomes inaccessible and breaks anything that depends on reading from it - Setting the setgid bit on a directory changes the group ownership of files subsequently created inside it
- A build directory made world-writable enables local privilege escalation if any privileged process later creates files there
None of these require writing a new file to an unexpected location. They modify the access control structure around existing paths. There’s nothing to scan for in the archive contents themselves, no suspicious-looking entry names, just mode bits applied through a carefully crafted symlink chain.
npm’s node-tar as a Reference Point
npm’s node-tar package went through a sequence of related vulnerabilities in 2021. CVE-2021-32803 and CVE-2021-32804 covered path traversal via symlinks, followed by CVE-2021-37701, CVE-2021-37712, and CVE-2021-37713, which exploited ways to circumvent the fixes applied in response to the earlier reports.
What the node-tar series illustrated clearly is that secure archive extraction is not a single invariant but a family of them that must hold simultaneously. The relevant invariants for tar extraction are roughly:
- Paths for file creation must not escape the destination directory
- Symlink targets must not point outside the destination directory
- The targets of metadata operations such as
chmodandchownmust resolve within the destination directory, even after following any previously extracted symlinks - The ordering of entries must not allow a combination of valid-looking individual steps to produce an invalid state
Patching property 1 while leaving property 3 unverified leaves the door open. Each of the node-tar follow-up CVEs exploited an interaction the previous fix hadn’t covered. CVE-2026-33056 in Rust’s tar crate is a different manifestation of the same underlying pattern: the permission-application code path was not receiving the same boundary validation that the file-creation code path had already received.
The Rust Team’s Response
The advisory describes a coordinated, layered response. On March 13, 2026, the crates.io team deployed a server-side change to reject uploads of crates exploiting this vulnerability, before any public disclosure. They also audited every crate ever published to crates.io and confirmed none were exploiting it. This closed the window for any further damage through the public registry.
The toolchain fix ships in Rust 1.94.1 on March 26, 2026, updating Cargo to use a patched version of the tar crate. Users on a current toolchain get extraction-level protection regardless of what any registry serves.
The credits in the advisory are worth reading. Eric Huss patched Cargo; Tobias Bieniek, Adam Harvey, and Walter Pearce handled the crates.io side and audited the existing crate corpus; Emily Albini and Josh Stone coordinated the response. Sergei Zimmerman discovered the underlying vulnerability and notified the Rust project ahead of time, enabling coordinated action before any public disclosure or known exploitation. William Woodruff directly assisted the crates.io team with the mitigations.
That sequence, private notification, server-side mitigation, full audit, then public disclosure with a toolchain fix ready, is what responsible handling of a supply chain vulnerability looks like. The fact that no exploiting crates existed on crates.io owes something to how rarely serious supply chain attacks against Rust materialize, but it also owes something to the response timeline.
The Alternate Registry Gap
The residual risk sits with alternate registries: private corporate instances, self-hosted Cargo registries, internal mirrors. The crates.io server-side mitigation does not extend to these automatically. A malicious crate published to an internal registry, whether through a compromised account or other means, can exploit this vulnerability on any Cargo version older than the patched release.
The advisory is explicit on this point: users of alternate registries should contact their registry vendor to verify whether protections are in place. Updating to Rust 1.94.1 is the reliable mitigation regardless of registry.
This gap is a recurring pattern in package registry security. The canonical public registry receives a central fix. Private infrastructure that mirrors or supplements it inherits the vulnerability until each operator acts independently. If your team runs internal builds against a private Cargo registry, that’s where to focus first.
Keeping Archive Extraction Honest
The tar format predates any notion of untrusted input. It was designed for backup and transfer, where the archive’s creator and consumer were the same person or organization. Every entry in a tar archive is a set of instructions to the extractor: create this path, with these permissions, with this content. Secure extraction requires validating each of those instructions against a consistent threat model.
Permission manipulation is quieter than file creation. It leaves no new files behind, and it bypasses the checks most developers think of first when they consider archive security. CVE-2026-33056’s relatively contained real-world impact, with no known exploiting crates on crates.io, owes more to coordinated disclosure timing than to the inherent difficulty of the attack.
Updating to Rust 1.94.1 is the right step. If you operate an alternate registry, review your crate validation pipeline with this class of attack in mind. If you rely on any library that extracts archives from untrusted sources, it is worth checking not just whether it validates file paths on creation, but whether it applies the same validation to every subsequent operation that resolves a path.