Tech and AI

A poisoned software package ran on every machine that compiled it, and it was live for 86 minutes

By Staff Writer  |  23 August 2026

The malicious code sat in a build script, so nothing had to call it. Compiling a project that pulled the package in was enough to execute it.

Somebody took over a maintainer account on the Rust package registry on 20 August and republished three of that maintainer's packages with one extra dependency added and everything else left alone. The added dependency was a near copy of a very widely used package, one character different in the name. Inside it, in the build script that the compiler runs automatically, was code that worked out the operating system and processor of the machine, downloaded a matching payload and ran it.

The three poisoned releases were online for 86, 90 and 107 minutes before the registry team deleted them. The package that matters most among the three has been downloaded around 245 million times in its life and more than 53 million times in the last ninety days, and it sits underneath cryptography, graphics and blockchain tooling that most of its users have never looked at directly.

We do not believe the author of arrayref to be acting maliciously, but their computer or credentials are likely compromised, and we are attempting to contact them

Manish Goregaokar, writing for the Rust Security Response Team

The part that makes this different

A poisoned library normally has to be called before it does anything. This one did not. Because the code was in a build script, the act of compiling a project that resolved the dependency was sufficient, and every build machine and continuous integration runner that pulled it in executed the payload with whatever rights that machine happened to have. Nobody had to use the library. They only had to build.

The attacker also removed the five previous good releases of the main package, so anyone resolving it afresh during those 86 minutes would have been pushed onto the poisoned one. The registry team has since restored the versions that were pulled.

The second stage went after saved credentials in the login databases of the common browsers and after the stored data of cryptocurrency wallet extensions, and it set itself to start again after a reboot on all three operating systems. Researchers at one cloud security firm say the infrastructure overlaps with earlier attacks attributed to North Korea, although attribution is not settled and the registry team has not said how the maintainer was compromised, how many people downloaded the poisoned versions, or how many machines ran the payload.

What to do about it on a project

The remedy published is narrow and worth passing to anyone who writes software in your business or buys it bespoke: search the local package cache for the deleted files, pin the affected package to a known good version, and where a build machine did pull one in, treat every credential, token and signing key reachable from that machine as compromised and rebuild it from a clean image.

The wider point is about digital delivery on projects. Design and engineering practices now run scripts, plugins and model checkers pulled from public registries into environments that hold client drawings, cost data and correspondence, and the security schedule in most consultancy appointments says nothing whatever about it. A schedule that requires antivirus on a laptop and is silent on the build pipeline is regulating the wrong machine. The right questions are where third party code enters, who approves a version change, and how quickly a compromised package can be identified and removed once the notice goes up.