I recently opened issue #6545 and I'm cross-posting here to ensure broader visibility of the mitigation. I've discussed this with the rust-lang security team, and we have agreed that it is appropriate to publicly discuss this issue and the proposed fixes. This issue does not affect users during a typical workflow. While there may be some window for social engineering, users do not typically run the affected commands from within an untrusted codebase.
If you use the affected functionality (or wish to be extra cautious), you are able to protect yourself with the workaround below while a fix is implemented and rides the release train.
If you have any reason to believe your private token may have been exposed, please visit https://crates.io/me to revoke your token and generate a new one.
The Issue
Cargo will fall back to the value of [registry.token] when a custom index is provided via the command line (--index) or specified via various source replacement ([source.*]) configuration options. Unless you specifically overrides this value, it will fall back to the value stored in $HOME/.cargo/config, which is almost always your token for the official crates.io registry.
As a point of clarification, this doesn't affect the alternative registry feature (via entries under [registries.*]) which is in the process of stabilization. Alternative registries are tangentially related, and the most likely fix is to make the problematic features mirror the alternative registries implementation.
Mitigation
Until you are running a patched version of cargo, if you specify an --index on the command line, you should ensure you provide a value for --token as well.
If you are working within a potentially untrusted codebase then you should create a .cargo/config file within a trusted parent directory containing the following:
[registry]
# Shadow my real crates-io token
token = "private"
This will protect you if you accidentally run one of the affected sub-commands: publish, yank, or owner. Of course, running sub-commands such as build or run on an untrusted codebase is still potentially dangerous.
If you are using source replacement in a mirroring or vendoring situation, then the affected sub-commands are not typically applicable. You should override the token as shown above as a precautionary measure. If you do need to run the affected sub-commands with source replacement, then you must ensure that the replacement index is trusted to always point to the official crates.io endpoint.
If you're using source replacement for anything else, then it's probably best to see if the alternative registry feature fits your use case. Alternative registries are currently an unstable feature, but the functionality is on track to stabilization.
More Info
You can find further details, proposed fixes, and discussion in issue #6545. This has also been cross-posted from the internals forum.