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...
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
You'd obviously already have cargo installed, which means you should be able to run a command against cargo to see if you are currently exposed to any security problems. Even if it's not the current "audit" add on.
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.
How to call it then : Yanked hard vs yanked soft ?
> A new version of the arrayref crate was published with a direct dependency on proc-macro1, which would execute a malicious build script.
> This compromised version was published on 2026-08-20 and removed approximately 86 minutes later, with no evidence of actual usage.
I don't know what more you want. Do you want the malicious version to continue to be available?
The version page [1] should show that for 86 minutes there was a version 0.3.10, it was malicious and was deleted with a link to the advisory. I get this takes time so even a generic "deleted" entry until they have time to link in the advisory would also be fine so we know something is happening.
Presumably even "deleted" crate versions still have some metadata left behind in the backend so this should be surfaced.