alt Hacker News> They're definitely not unprepared for an incident like this.
We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised.
`cargo audit` should be reporting if these packages have been downloaded. The "What you need to do" section of the blog should be run `cargo audit`
> Not having an advisory INSTANTLY available isn't a sign of a decaying org. Chill.
The GitHub issue was opened 8 hours ago. The cargo.io team also acknowledged it 8 hours ago. [2]
> [3] is no longer true.
Previously published versions shouldn't just disappear from the list. There's still nothing there to indicate a version was yanked.
[1]: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
[2]: https://rust-lang.zulipchat.com/#narrow/channel/318791-t-cra...
Replies
It wasn't yanked, it was fully removed.
They did that because a yanked package can still be used. And in this case there weren't any downloads, so it is unlikely the malicious package was actually used.
> We shouldn't need to resort to pasting `find` commands [1] into the shell from blog posts to tell if we're compromised.
I know you recommended `cargo audit`, but that is not nearly as universally installed as `find`. And as far as I know, cargo-audit has to be run within a project directory? Can it be run outside of the context of a project and scan the cargo registry cache?
I personally appreciated having the `find` command:
* It very clearly indicates where to look (my cargo registry cache)
* It very clearly indicates what files to look for (a list of wildcards)
* It's something that I can easily review and then copy/paste into my terminal
* I can very easily adapt it to my particular environment (perhaps into a `fd` invocation if I'm on Windows, or perhaps adapt it to scan all home directories on my system), or feed these file names into some other vulnerability scanner