The Rust project has warned that someone is going after its contributors and crate owners. Not after the code: after the people who hold publishing rights. The end goal is the package registry, and the route in is a job offer.
What happened
Adam Harvey, a security-focused engineer, laid it out on the official Rust blog. The pattern reminds him of the fake recruiter campaigns attributed to North Korea: a video call is arranged over something appealing — a role, a contract, a project to collaborate on — and the call is the delivery mechanism. Either you're pushed into installing something (the classic missing audio codec, so they can hear you), or into running a command that was already sitting in your clipboard.
What makes it work isn't the technique, it's the set dressing:
These attackers stand up brand-new but legitimate-looking company profiles, plausible LinkedIn presence included, so they survive a quick check.
And a quick check is the only one almost anybody does.
The warning follows a busy summer. In June there were approaches from a supposed investment firm based in Singapore; one of the maintainers who publishes on crates.io dug into it and found the company that claimed to be recruiting him no longer existed. Even so, the first contact was convincing, and he came within an inch of having a remote access trojan — a RAT: remote control of your machine — running inside his kit.
That lines up with the joint advisory published the previous week by agencies in Australia, Germany, Japan and the United States: North Korean operators are said to have compromised more than thirty thousand devices using fake interviews, stealing over ten million dollars.
And in parallel, in August, the ecosystem already took a supply chain hit: malicious versions of the arrayref crate were published, pulling malware onto the machine of whoever built with it. arrayref has racked up two hundred and forty-five million downloads over its lifetime. The poisoned releases were up for less than two hours, and the evidence points to stolen maintainer credentials rather than someone on the project doing harm on purpose.
Why it matters if you build software
Put the two pieces together and the picture is plain: the weak link in a package with hundreds of millions of downloads is a laptop. One. Belonging to a person who, on top of maintaining the library, keeps their SSH keys, their registry session and their publishing token on it.
This hits home for me, because that's exactly what I am: one person. And it probably applies to you too, even on a big team, because the account that pushes the release usually belongs to someone specific.
Things I'd change today, on the publishing side:
- No third-party code on the machine that publishes. If someone sends you a repo for a "technical exercise", it gets opened in a throwaway VM or a container with no credentials inside. An
npm installor acargo buildruns arbitrary code, and the exercise is the vector. - Never paste the clipboard blindly into a terminal. That trick works because the command you saw and the command you copied aren't the same. Paste it into the editor first, read it, then decide.
- No legitimate call needs you to install a codec. If the platform asks for a binary so people can hear you, the meeting is over. Video calls on known tools, full stop.
- Publishing tokens with minimum scope and an expiry date, second factor on the registry account and, where possible, publishing from CI with a verified identity instead of an eternal token sitting in your home directory.
And on the dependency-consuming side, which is all of us:
- Reproducible installs in CI. Build from the lock file as-is and fail if it doesn't match. If your pipeline resolves fresh versions on its own, a two-hour window is plenty to reach you.
- Ask yourself now whether you could answer this: did your CI pull that dependency during that specific window in August? If the answer is "we'd have to look into it", the problem isn't the crate, it's your traceability. Keep resolution logs and an inventory of what goes into each build.
- Quarantine new versions of small, heavily used dependencies. Tiny libraries are the best target: nobody reads the diff of a two-hundred-line package that's been boring for years.
- Automated advisory checks on every build, not once a quarter.
The underlying lesson: the security of your supply chain depends on the operational hygiene of people you don't know and who owe you nothing. You can't audit that. All you can do is shrink your exposure window and know, from logs, what came in and when.
What does NOT change
Let's be honest about the limits, because this is being framed as "a Rust problem" and it isn't.
It's not a Rust flaw. The same script has been used against npm, against PyPI and against editor extensions. The language's memory safety won't protect you from a tired engineer pasting a command at eleven at night. Different layers of the problem.
The big numbers aren't Rust's. The thirty-thousand-plus devices and the ten-million-plus dollars in the international advisory cover broad campaigns against all sorts of technical profiles, not the crate ecosystem. Mixing them up is headline-writing.
There's no sign of a wholesale compromised ecosystem. August was stolen credentials and the window was short. That doesn't make it harmless, but it isn't "the registry has fallen" either.
Two-factor isn't a silver bullet. If the trojan is already inside, the open session belongs to them too. 2FA raises the cost of stealing the account from outside; it doesn't rescue an infected machine.
And the awkward counterweight: you can't treat every recruiter message as an attack, because that's how real opportunities get lost. The sensible advice is Harvey's: scrutinise unsolicited approaches even when they look legitimate, and move the conversation onto trusted platforms. That, plus never running a stranger's code on the machine holding your keys, covers nearly everything.
Any questions, tell me and we'll go through it.
Best, Vicente.