Cargo’s Registry Boundary Breaks in Two Places: What Rust Builders Must Audit

Cargo’s security boundary is not only the compiler. It also includes registry URLs, authentication tokens, archive extraction, and the local source cache. Two advisories published by the Rust Security Response Team on May 25, 2026 make that boundary visible.

The first issue, CVE-2026-5222, affected Cargo versions shipped from Rust 1.68 through before Rust 1.96. Cargo reused a URL-normalization rule from Git-based registries when handling sparse registries. In a narrowly defined hosting arrangement, https://example.com/index and https://example.com/index.git could be treated as sharing credentials even though an HTTPS server could treat them as different resources. An attacker able to publish to one registry and upload files to the other could construct a dependency that caused a victim’s Cargo token to be sent to the malicious registry.

The second issue, CVE-2026-5223, concerned symlinks inside crate tarballs from third-party registries. Cargo’s extraction safeguards prevented a file from escaping the crate’s cache directory, but a crafted archive could write one level below that directory and overwrite the cached source of another crate in the same registry. That creates a supply-chain integrity problem: a later build could consume source that no longer matches the expected package.

The two bugs are different, but the engineering lesson is shared. A package manager must treat registry identity as an authorization decision and extracted source as security-sensitive state. A syntactic normalization shortcut can leak credentials; a filesystem edge case can change what code a build compiles.

Rust 1.96.0 added the relevant fixes. For CVE-2026-5222, Cargo strips .git only for registry URLs using the Git protocol. For CVE-2026-5223, Cargo rejects symlinks in crate tarballs. The official advisory says crates.io users are not affected by the symlink issue because crates.io already forbids uploading crates containing symlinks. The sparse-registry issue instead depends on a much narrower combination of third-party registry hosting and publishing permissions.

That distinction should shape an ICP·Dev build policy. First, identify whether CI or developer machines use alternate registries, mirrors, or private sparse indexes. Second, pin and verify the Cargo version supplied by the toolchain image rather than assuming the host’s rustup state is current. Third, ask registry operators whether they reject symlinks and isolate registry namespaces at the HTTP and credential layers. Finally, treat Cargo tokens as credentials that must never cross registry boundaries merely because two URLs look similar.

As a current scoring caveat, the NVD record shows both Rust’s CVSS-B 2.3 Low assessment and NIST’s CVSS 3.1 6.5 Medium assessment for CVE-2026-5222. Those numbers use different scoring views; the practical response is to check exposure conditions, not to infer risk from one label alone.

The broader takeaway is modest but important: Rust’s memory-safety guarantees do not automatically secure the package supply chain around a Rust build. For teams using private registries, upgrading Cargo is necessary, but registry isolation, archive policy, and reproducible-build checks remain part of the trusted computing base.