[<prev] [next>] [day] [month] [year] [list]
Message-ID: <a6c44ea0-fb8e-4a61-a59d-13ae88f1b6f0@oracle.com>
Date: Thu, 28 May 2026 11:04:55 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Two security advisories for Cargo from Rust
The following advisories have been posted to both https://blog.rust-lang.org/
and https://groups.google.com/g/rustlang-security-announcements/ earlier this
week:
> # CVE-2026-5222: Cargo can be coerced to share credentials between registries
>
> The Rust Security Response Team was notified that Cargo incorrectly normalized
> the URLs of third-party registries using the [sparse index protocol][1]. If a
> hosting provider allowed multiple registries to be hosted with arbitrary names
> within the same domain, an attacker able to publish crates in a registry could
> obtain the credentials of others users of the same registry.
>
> This vulnerability is tracked as CVE-2026-5222. The severity of the
> vulnerability is **low**, due to the extremely niche requirements needed to
> achieve the attack.
>
> ## Overview
>
> Originally Cargo only supported storing a registry's index within git
> repositories. Most git hosting solutions allow accessing a git repository with
> or without the `.git` suffix, so Cargo mirrored this behavior when normalizing
> registry URLs. This allowed credentials for `https://example.com/index` to be
> used for `https://example.com/index.git`.
>
> This normalization was unintentionally applied to the new sparse indexes too.
> Sparse indexes can be hosted on any HTTPS server, which treat URLs ending with
> `.git` as different URLs than those without the suffix.
>
> If the following conditions apply:
>
> * `https://example.com/index` is a sparse index.
> * `https://example.com/index` allows crates to depend on crates from any other
> registry.
> * The attacker is able to publish crates on `https://example.com/index`.
> * The attacker is able to upload arbitrary files to
> `https://example.com/index.git`.
>
> ...the attacker could configure `https://example.com/index.git` to be a Cargo
> sparse registry requiring authentication for downloads, and with a download URL
> pointing to a server recording any credentials set to it.
>
> When the attacker then publishes a crate `foo` to `https://example.com/index`
> depending on a crate `bar` from `https://example.com/index.git`, and tricks the
> victim into downloading `foo`, Cargo will think the two registries share the
> same credential and send the victim's Cargo token to the malicious registry.
>
> ## Mitigations
>
> Rust 1.96, to be released on May 28th, 2026, will update Cargo to only strip the
> `.git` suffix from registry URLs using the git protocol. No mitigations are
> available for users of older versions of Cargo.
>
> ## Affected versions
>
> All versions of Cargo shipped between Rust 1.68 (the stabilization of sparse
> registries) and 1.96 are affected.
>
> ## Acknowledgements
>
> We'd like to thank Christos Papakonstantinou for reporting this to us according
> to the [Rust security policy][2].
>
> We also want to thank the members of the Rust project who helped us address the
> vulnerability: Arlo Siemens for developing the fix; Weihang Lo, Eric Huss and
> Emily Albini for reviewing the fix; Emily Albini for writing this advisory;
> Emily Albini, Josh Stone and Manish Goregaokar for coordinating the disclosure.
>
> [1]: https://doc.rust-lang.org/cargo/reference/registries.html#registry-protocols
> [2]: https://rust-lang.org/policies/security
> # CVE-2026-5223: Crates in third party registries can override the cached source of other crates
>
> The Rust Security Response Team was notified that Cargo incorrectly handled
> symlinks inside of crate tarballs downloaded from third-party registries,
> allowing a malicious crate to override the source code of another crate from the
> same registry.
>
> This vulnerability is tracked as CVE-2026-5223. The severity of the
> vulnerability is **medium** for users of third-party registries. Users of
> crates.io are **not affected**, as crates.io forbids uploading crates containing
> any symlink.
>
> ## Overview
>
> When building a crate, Cargo extracts its source code in a local cache (stored
> within `~/.cargo`), reusing it for any future build. Cargo includes protections
> to prevent any file from being extracted outside of the crate's own cache
> directory.
>
> It was discovered that it's possible to craft a malicious tarball able to
> extract files one level below the crate's own cache directory. With the way the
> cache is structured, that allowed the malicious crate to override the cache of
> other crates belonging to the same registry.
>
> ## Mitigations
>
> Rust 1.96.0, to be released on May 28th, 2026, will update Cargo to reject
> extracting *any* symlink within crate tarballs, regardless of whether they come
> from crates.io (which already forbids them) or third-party registries. Note that
> Cargo never added symlinks when running `cargo package` or `cargo publish`, so
> the impact of this should be minimal.
>
> Users who are not able to upgrade to the most recent Rust version are
> recommended to audit the contents of their registry for the presence of any
> symlink, and to configure their registry to reject symlink (if such option is
> available).
>
> ## Affected versions
>
> All versions of Cargo shipped before Rust 1.96.0 are affected.
>
> ## Acknowledgements
>
> We'd like to thank Christos Papakonstantinou for reporting this to us according
> to the [Rust security policy][1].
>
> We also want to thank the members of the Rust project who helped us address the
> vulnerability: Josh Triplett for developing the fix; Arlo Siemsen for reviewing
> the fix; Emily Albini for writing this advisory; Emily Albini, Josh Stone and
> Manish Goregaokar for coordinating the disclosure; Ed Page and Eric Huss for
> advising during the disclosure.
>
> [1]: https://rust-lang.org/policies/security
--
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
