Fake interviews target Rust maintainers' publishing rights, and arrayref showed what one stolen account does

2,285 downloads, and not one bad line in arrayref

On 20 August 2026 a new release of arrayref, a small Rust crate with more than 266 million lifetime downloads, sat on crates.io for 86 minutes. According to the RustSec advisory, it was downloaded 2,285 times before it was removed. That is about 27 downloads a minute. The library code in that release was not the problem. The release added one dependency, proc-macro1, whose build script downloaded a malicious payload, and Cargo runs a dependency's build script automatically as part of cargo build.

Four weeks later, on 17 September, the Rust project warned that an ongoing campaign is targeting rust-lang members and owners of popular crates with fake job, project and contract video calls. Its stated aim is to compromise devices and accounts "in order to use them to publish malware". The Register reported the warning on 21 September, four days later.

The arithmetic is worth doing before reading anything into the 2,285. At arrayref's current rate of about 57.5 million downloads per 90 days, 86 minutes of normal traffic across all versions is roughly 38,000 downloads. The poisoned version took about 6 per cent of that, which fits RustSec's own statement that it was "less than 10%" of the crate's traffic because most users already had older versions locked. Lockfiles did most of the defending that morning.

Here is what those figures do not establish. A download is not a build, and a build is not a confirmed infection: no source I read gives a count of compromised machines. The Rust project does not say that arrayref fell to a fake interview specifically. It says the crate was compromised "through similar attacks", and adds that it does not know whether the June incident, the arrayref compromise and the current campaign are the same operation. And it does not attribute the campaign to North Korea. It says the attack style is known to be used by the DPRK, which is a statement about technique, not about who is behind these calls.

What the Rust project actually said, and what it left out

The primary warning is a short post by Adam Harvey on the Rust blog, written on behalf of the crates.io team and the security response working group. It is worth reading in full because it is careful about what it claims. I found no separate statement from the Rust Foundation. The table sets out the post against the questions a defender will ask.

The Rust project's warning of 17 September 2026, claim by claim. Source: Rust blog, Be alert: targeted attacks on prominent Rustaceans.

Question	Stated	Not stated
Who is targeted	rust-lang members and owners of popular crates	How many people were approached
The lure	A video call about a job, project or contract	Which platforms or company names
The ask	Install something, such as a supposedly missing audio codec, or run a command put on the clipboard	The payload, its name or its hashes
The goal	Compromise devices and accounts to publish malware	Whether any account was compromised in September
Cover story	New but legitimate seeming company profiles, plausible LinkedIn presences	Any indicators of compromise
Link to earlier incidents	June attack on prominent Rust developers; arrayref compromised through similar attacks	Whether they are one campaign (it says this is not known)
Attribution	Attack style known to be used by the DPRK	That this campaign is DPRK

The advice in the post is equally modest: be suspicious of cold outreach, hold calls on platforms you trust and ideally set them up yourself, and check that accounts look normal with MFA on and no unexpected logins. Concerns go to help@crates.io or security@rust-lang.org. There is nothing wrong with that advice. The point is that it is aimed at the maintainer's judgement, and it leaves the downstream consumer, which is most UK organisations, with no action of their own. The rest of this briefing is about that consumer.

Three incidents, one pattern

The warning links two earlier events. Read together with a third, they show a pattern that moves from the individual to the registry.

The incidents the Rust warning links to, with days counted to the warning of 17 September 2026. Sources: grack.com, Rust blog, RustSec, ashishb.net.

Date	Event	Days before warning
16 May 2026	A developer publishes two fake technical adviser approaches, each asking him to run an npm project	124
25 June 2026	Matt Mastracci publishes his near miss: a fake venture capital approach and a booby-trapped take-home repo	84
20 August 2026	arrayref, internment and append-only-vec republished with a malicious build-time dependency	28
17 September 2026	Rust project warns of an ongoing campaign against maintainers	0

June: the take-home test. Matt Mastracci, who publishes crates on crates.io, describes an approach from a persona claiming to be from a defunct Singapore venture capital firm, a video call with the camera off, and then a "test" repository. His instructions ended by asking him to run the typecheck, test suite and build commands before submitting. The repository was TypeScript, and the trap was a patch file that injected a loader into the TypeScript compiler, so the first typecheck or build would start a remote access trojan. He calls it PinpinRAT; the name comes from its internal strings and he found no other references to it. Its commands included dumping the environment, uploading any file, and spawning processes. He caught it because a TypeScript task made no sense for a Rust maintainer. His closing line is the reason this briefing exists: had it been a Rust repository with a booby-trapped build.rs, he writes, "I might have even fallen for it".

August: the poisoned release. The Rust security response team says a report arrived that proc-macro1 was malicious and carried a build script downloading a payload. It then found that arrayref had been republished to depend on it, with recent versions yanked. It removed the malicious versions, reversed the yanks, locked the owner's account, and said it did not believe the author was acting maliciously: their computer or credentials were likely compromised.

September: the warning. The call, the codec and the clipboard. No payload is named.

Why cargo build runs a stranger's code

Rust developers often assume that compiling is safe and running is dangerous. The Cargo documentation says otherwise. A file named build.rs in a package root makes Cargo compile that script and execute it just before building the package, and the script "may perform any number of tasks". It runs as you, with your files, your environment variables and your network. Procedural macros are the second route: the Rust reference says they run during compilation and have the same resources as the compiler, and "have the same security concerns" as build scripts.

Three details from the arrayref records show how little an attacker needs from that design.

• The dependency was the weapon, not the crate. The original report to RustSec, filed at 07:54 UTC, says proc-macro1 shipped the genuine proc-macro2 source so that builds succeeded, with a build.rs that pieced together a download address from base64 fragments, fetched a binary over TLS with certificate checks switched off, and ran it. The same report says the child process was deliberately abandoned, with an in-source comment about escaping Cargo's job object, so the build did not wait for it.
• The registry's safety signal became the lure. According to StepSecurity, which says it checked the crates.io audit log, versions 0.3.5 to 0.3.9 were yanked in a burst between 07:15:24 and 07:15:40. The reporter says that is how he was hit: Cargo's advice to move off a yanked version resolved to the one release that was not yanked, which was the poisoned one.
• It was quick. From the malicious proc-macro1 release at 07:11:15 to the last deletion at 09:25:24 is 2 hours 14 minutes. The three legitimate crates were poisoned between 07:15:00 and 07:37:49, a span of 22 minutes 49 seconds.

Merely opening the project can be enough. The rust-analyzer configuration lists cargo.buildScripts.enable and procMacro.enable as true by default, so an editor running rust-analyzer will run build scripts and proc macros to analyse the code. The VS Code extension declares that it does not support untrusted workspaces, warning that a malicious actor could use it "to run arbitrary code on your machine". So in VS Code the only thing between opening a hostile Rust repository and running its build script is the Workspace Trust prompt, and VS Code's documentation notes that trusting a parent folder trusts every subfolder under it. By the same documented life cycle, cargo check has to run build scripts before it can check a package; that is my reading of the Cargo book rather than a separate statement in it.

The friendly name is not a control

Most of the protection developers believe they have here comes from reassuring words. Each one describes an intention, not a boundary.

Comforting labels in this story and what they actually do. Sources: Cargo book, Rust reference, rust-analyzer and VS Code documentation, RustSec issue 3161, StepSecurity.

Label	What it suggests	What it does
cargo build, cargo check	Compiling, not running	Runs every dependency's build script and proc macros as you
Yanked	This version is bad, move on	Only a signal; in August it herded users to the poisoned release
Audio codec, driver, fix	A harmless install to make the call work	Software from a stranger, run with your privileges
Take-home test	A coding exercise	In June, a build command that started a RAT
Trusted folder	I checked this repo	Trust extends to every subfolder, including the next clone
cargo audit clean	We were not affected	Advisories for deleted malware arrived hours later; check lockfiles and caches
It is Rust	Memory safe, so safe	Memory safety says nothing about what a build script is allowed to do

The cargo audit row deserves a note. On the day, a commenter in the RustSec issue pointed out that deleted malicious versions produced no audit signal. Advisories were then added, and the OSV record for RUSTSEC-2026-0260 is dated 20 August. A clean audit today will catch arrayref 0.3.10. It will not catch the next one in the hours before an advisory exists, and a warm ~/.cargo/registry cache or a vendored copy keeps building a version the registry has deleted.

Attribution: separate the method from the accusation

The Rust post links to Kudelski Security research on the Contagious Interview campaign as evidence that the style is DPRK tradecraft. That research describes fake interviews run over LinkedIn, WhatsApp and Discord, repositories that trigger a backdoor on npm install or when opened in VS Code, and theft of the whole process environment. The joint advisory of 18 September from Japanese, US, Australian and German agencies describes the same technique at scale, at least 30,000 PCs in more than 100 countries between December 2025 and July 2026, and we covered it here. That advisory talks about npm and VS Code projects. It does not mention Rust, Cargo or crates.io.

So the honest position is this. The technique matches a documented North Korean campaign. No primary source I read says these Rust approaches were made by North Korea, and Mastracci himself writes that who was behind his attempt is for the agencies to decide. The defender does not need the attribution to act, because the controls are the same whoever is calling.

Some interests are worth declaring. StepSecurity, whose timeline I rely on for the yank sequence, sells the runtime monitoring product it uses to demonstrate detection. Kudelski sells detection and response services. None of that makes their evidence wrong; the registry timestamps they cite match the Rust project's own. It is a reason to take their product conclusions as sales material and their data as data.

What isolation actually works

The Rust project's advice is to be suspicious. That is necessary but it is not a control, because the whole technique is built to pass cursory inspection. What stops a build script is where it runs and what it can reach.

Isolation options for running unfamiliar Rust code, judged against what a hostile build script does. Mechanism sources: Cargo book, Rust reference, rust-analyzer and VS Code documentation; judgements are the author's.

Option	What it stops	What it does not stop
Reading the code first	Obvious payloads in the top-level build.rs	Payloads in a dependency, a proc macro or a patch file
VS Code Restricted Mode	rust-analyzer and tasks running on open	Anything you run once you click trust or open a terminal
Container with nothing mounted and no network	Credential theft and payload download	Container escape, and it fails the moment you mount your home or SSH agent
Disposable VM or cloud machine, no secrets	Theft from your real machine; destroyed afterwards	Anything you type into it, such as a token or password
Egress allowlist in CI	Payload download and callback to a bare IP	A payload embedded inside the crate itself
Committed Cargo.lock and --locked builds	Silent resolution to a brand new release	A poisoned version you deliberately update to
Trusted publishing for releases	Long-lived crates.io tokens in CI secrets	A maintainer's stolen browser session or local token

For maintainers specifically, crates.io has supported trusted publishing since July 2025, which lets GitHub Actions request a short-lived publishing token through OpenID Connect instead of storing an API token. The arrayref publishes came from the owner's own account without a matching commit in the project repository, according to StepSecurity, which is exactly the path trusted publishing is designed to make unnecessary. Whether the account used a token or a session is not stated in the Rust project's post.

What this means for a UK organisation

Most UK organisations are not maintainers. They are consumers of crates, through their own Rust services, through tools their engineers install with cargo install, and through vendor software built on these libraries. Three exposures follow.

• Your builds. Any build that resolved arrayref 0.3.10, internment 0.8.7, append-only-vec 0.1.9 or any version of the attacker crates during the window ran the payload on that machine or runner, with whatever secrets it held.
• Your engineers as targets. Anyone on your team who maintains a popular crate is exactly who this campaign wants, and the approach arrives on their personal LinkedIn and personal laptop, outside your EDR and SSO logging.
• Your hiring. If your own interview process asks candidates to clone and build a repository, you have taught them the behaviour the attacker relies on.

No UK agency is named in the Rust warning, and no UK victim is recorded in any source I read.

# Check a developer machine or CI cache for the deleted malicious crates
# (command published by the Rust security response team, 20 August 2026)
find ~/.cargo/registry/cache -type f \( \
  -name 'append-only-vec-0.1.9.crate' -o \
  -name 'arrayref-0.3.10.crate' -o \
  -name 'internment-0.8.7.crate' -o \
  -name 'proc-macro1-*.crate' -o \
  -name 'proc-macro-en-*.crate' -o \
  -name 'aovine-*.crate' -o \
  -name 'arone-*.crate' -o \
  -name 'aronenao-*.crate' -o \
  -name 'tinymember-*.crate' \
\) -print

# Check committed lockfiles across your repositories
grep -rEn 'proc-macro1|proc-macro-en|aovine|arone|aronenao|tinymember' --include=Cargo.lock .
grep -rEn -A1 'name = "(arrayref|internment|append-only-vec)"' --include=Cargo.lock . | grep -E '0\.3\.10|0\.8\.7|0\.1\.9'

What to do, in the order worth doing it

The question that exposes the gap

The Rust project's advice relies on a maintainer noticing that a pleasant video call is a trap. Mastracci noticed only because the language was wrong. So the question for any organisation that builds Rust is not whether your developers are careful. It is this: if a trusted maintainer's account published a poisoned release tomorrow morning, which of your machines would run its build script before anyone in the Rust project had written a word about it, and what secrets would be sitting on them?