On 20 August three packages by the same author in the Rust registry come out with a new dependency whose build script downloads and runs a malicious payload during compilation. They were deleted within an hour and a half to two hours. The maintainer's account is locked - the Rust team believes their computer or their access credentials were taken over.
- arrayref@0.3.10, internment@0.8.7 and append-only-vec@0.1.9 come out with a new dependency, proc-macro1, whose build script downloads a malicious payload at compile time.
- They are online between 86 and 107 minutes and are deleted from crates.io; the author's account is locked, there is no CVE number.
- The check goes through ~/.cargo/registry/cache: that is where you see whether the machine built the poisoned code at all.
Eighty-six minutes. That is how long the poisoned arrayref sat in the public Rust registry before they deleted it. Sounds like good news.
It is not. That package does not wait for you to run the program to do its job. It fires while you compile. Anyone who built a project on Thursday morning with the new version has already run somebody else's binary on their machine - and deleting it from the registry does not undo that.
Compilation is the moment
In Rust every package can carry a build script - a piece of code that runs before the actual build, to prepare something. Legitimate work. And full access to the machine at a moment when nobody is watching, because everybody is watching the result of the compilation, not the road to it.
That is why the name proc-macro1 is no accident. The real package is called proc-macro2 and sits under half the ecosystem. An eye running down a list of dependencies at seven in the morning sees a familiar word and moves on.
What the researchers say
Per Wiz the second-stage payload works on Linux, Windows and macOS, collects machine name, user and a list of installed programs, digs into the profiles of Chrome, Brave and Edge for saved passwords, and calls a command server over HTTPS. The same firm says it finds arrayref in more than 35 percent of the environments it reviews, and in three quarters of those where anybody writes Rust.
Wiz also points to overlaps with North Korean campaigns: the address the payload calls is the same as in the Mastra campaign, which Microsoft attributes to the group Sapphire Sleet. That is a claim by researchers, not an established fact. It is heavy, but it is a direction for the investigation.
Check the cache, not the project
There is nothing to update here. The poisoned versions are already gone from the registry and your dependency list today points at clean ones. The question is whether the machine compiled during those two hours, and the answer sits in ~/.cargo/registry/cache - the Rust team gives a ready command that looks for exactly those files by name.
Find even one of them and the machine built the poisoned code. From there on you change everything it has access to: keys, tokens, passwords in the browser.
The response was fast and that has value - for the next person who would have reached for the package. For whoever compiled on Thursday morning it changes nothing.