GHSA-p688-r7jv-fm6f CVE-2026-5222
Cargo can be coerced to share credentials between registries
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- 0.48%
- Chance of exploitation in the next 30 days. Higher than 41.26% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-647 Use of Non-Canonical URL Paths for Authorization Decisions
- Fix
0.97.0- Upgrade cargo to this version or later
Description
The Rust Security Response Team was notified that Cargo incorrectly normalized the URLs of third-party registries using the sparse index protocol. 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/indexis a sparse index.https://example.com/indexallows 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
Cargo would like to thank Christos Papakonstantinou for reporting this issue according to the Rust security policy.
Cargo also wants to thank the members of the Rust project who helped 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.
Affected versions
crates.io
| Package | Vulnerable | Fixed in |
|---|---|---|
| cargo | < 0.97.0 |
0.97.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
cargo crates.io → 0.97.0
- cargo
cargo update -p cargo --precise 0.97.0
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- Passive
- Confidentiality (vulnerable system)
- Low
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- Low
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 6.5
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-647: Use of Non-Canonical URL Paths for Authorization Decisions
The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.
How to prevent it
- Architecture and Design: Make access control policy based on path information in canonical form. Use very restrictive regular expressions to validate that the path is in the expected form.
- Architecture and Design: Reject all alternate path encodings that are not in the expected canonical form.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-jq42-7mfv-hm57 Cargo crates in third party registries can override the cached source of other crates | Medium | Also affects cargo |
| GHSA-wrrj-h57r-vx9p Malicious dependencies can inject arbitrary JavaScript into cargo-generated timing reports | Medium | Also affects cargo |
| GHSA-j3xp-wfr4-hx87 Cargo not respecting umask when extracting crate archives | High | Also affects cargo |
| GHSA-r5w3-xm58-jv6j Cargo did not verify SSH host keys | Medium | Also affects cargo |
| GHSA-2hvr-h6gw-qrxp Cargo extracting malicious crates can fill the file system | Medium | Also affects cargo |
| GHSA-rfj2-q3h3-hm5j Cargo extracting malicious crates can corrupt arbitrary files | High | Also affects cargo |
| GHSA-9f3p-wvj7-q82x Cargo prior to Rust 1.26.0 may download the wrong dependency | High | Also affects cargo |
| GHSA-7rc3-g7h6-22m7 File Browser: Colliding username normalization gives two users the same home directory | High | Same weakness, CWE-647 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor