Last week the Rust Security Response Team published an advisory for CVE-2026-33056, a vulnerability in the third-party tar crate that Cargo uses to extract packages during a build. The short version: a specially crafted .crate file could change permissions on arbitrary directories on the filesystem, not by executing code, but simply by being extracted.
This is worth understanding carefully, because it sits in an unusual spot in the threat model that most Rust developers carry around in their heads.
The tar format and what extraction actually does
A .crate file is a gzipped tar archive. When Cargo downloads a dependency and extracts it into ~/.cargo/registry/src/, it’s doing exactly what tar xzf does from the command line: reading a sequence of entries from the archive, each of which carries a path, content, and metadata. That metadata includes Unix permission bits.
The standard tar header format has a 12-byte mode field for each entry. For file entries, this sets the familiar read/write/execute bits. For directory entries, it does the same. And here’s the relevant part: tar implementations are supposed to apply those mode bits to the directory they create or encounter during extraction.
The vulnerability tracked as CVE-2026-33056 is in how the tar crate handled directory entries whose paths traversed above the extraction root. A malicious archive could include an entry like ../../../home/user with mode 0000, and if the implementation followed the path and applied the chmod, the attacker just locked the victim out of their home directory, without writing a single file.
This is distinct from path traversal (the class of bug sometimes called Zip Slip, where archive entries write files outside the intended extraction directory). In Zip Slip, the payload is file content. Here, the payload is a permission change. No file is written, no executable lands on disk, but the filesystem state is still modified in a way the user did not intend.
Where this sits in Cargo’s build lifecycle
The build model that most Rust developers think about goes something like: Cargo resolves the dependency graph, downloads crates, compiles them, and runs any build.rs scripts. The conventional wisdom is that you need to worry about untrusted code at the build.rs stage, because that’s when the crate’s Rust code actually executes.
CVE-2026-33056 happens before any of that. The attack fires during extraction, which occurs before compilation and before build.rs runs. This means it’s not gated by --offline, it’s not visible in cargo audit as a code-level dependency, and it bypasses the mental model most developers use when reasoning about crate trust.
The practical impact depends on what user account runs the build. On developer machines, that’s typically a user account with ownership over a home directory and a project tree. Changing permissions on ~/.cargo itself, or on the project’s source directory, or on any other directory the attacker can reach via path traversal, could disrupt subsequent builds, lock the user out, or in the right circumstances, pave the way for a secondary attack.
On CI systems where builds run as a service account with broader permissions, the blast radius widens.
How the response was structured
The advisory credits Sergei Zimmerman with discovering the underlying tar crate vulnerability and notifying the Rust project ahead of disclosure. William Woodruff assisted the crates.io team with mitigations directly.
crates.io deployed a server-side check on March 13th to block uploads of crates that would exploit this vulnerability. The team also performed a full audit of every crate ever published to the registry and confirmed that none of them were exploiting CVE-2026-33056. For users of the public registry, that’s a clean bill of health.
The patch ships in Rust 1.94.1 on March 26th, 2026, which upgrades the tar crate to a version that no longer applies permission changes to directories outside the extraction root.
The alternate registry problem is real
The advisory is clear about one thing: users of alternate registries are in a different position. crates.io’s audit covered crates.io. Private registries hosted on Artifactory, Cloudsmith, or self-hosted tooling have no equivalent guarantee.
This matters more than it might seem. Enterprise Rust adoption has grown significantly over the past few years, and a substantial portion of that usage involves internal registries that mirror or supplement crates.io. Companies in regulated industries often route all package traffic through internal artifact stores, sometimes with lax validation on what gets published internally.
The Rust team’s advice is direct: contact the vendor of your registry to verify whether you are affected. But realistically, many private registries do minimal validation of .crate files beyond signature checking, and some do none at all. Until those users upgrade to 1.94.1, they’re relying entirely on the trustworthiness of whoever can publish to their internal registry.
This is the category of supply chain risk that is hardest to reason about: not the public attack surface that the community can audit collectively, but the internal one that each organization has to assess on its own.
Prior art in archive extraction vulnerabilities
The npm ecosystem dealt with a closely related problem. The tar npm package, which the npm CLI depends on for tarball extraction, received multiple CVE patches in 2021 (including CVE-2021-32803 and CVE-2021-32804) for path traversal vulnerabilities where symlinks could be used to write files outside the extraction directory. Those were Zip Slip variants rather than permission manipulation, but the underlying cause is the same: archive extraction is a parsing problem, and tar’s format has enough expressive power to encode operations that should not be performed outside a sandboxed context.
The Python wheel format, used by pip, has its own extraction-time vulnerabilities in its history, including issues with how symbolic links were handled during installation. The pattern is consistent across ecosystems: archive-based distribution formats were designed for trusted contexts and have been gradually hardened as they became vectors for untrusted content.
Rust’s tar crate has been the standard choice for this work since early in the ecosystem’s history. It’s maintained carefully and has a small, focused API surface. But no implementation is immune to this class of bug, and the right long-term answer probably involves more structured validation at the Cargo level rather than relying solely on the extraction library to make safe decisions.
What to do
If you’re on crates.io exclusively and you update to Rust 1.94.1, you’re in good shape. The public registry was clean before the patch, and the patched tar crate eliminates the vulnerability going forward.
If you use an alternate registry, upgrade to 1.94.1 and separately verify with your registry provider that no affected crates are present. If you’re running CI with an older pinned toolchain, treat that as a risk to evaluate: build environments that download from internal registries on old Cargo versions remain vulnerable regardless of what crates.io does.
For teams that run security reviews of their Rust supply chain, the broader lesson here is that extraction is a phase worth modeling explicitly. The threat surface of a build does not start with build.rs. It starts the moment Cargo opens a .crate file.