Rust Warns of Fake Video Calls Targeting Popular Crate Owners

On 17 September 2026 the crates.io team and the Rust security response working group published a warning: they believe an ongoing campaign is targeting rust-lang members and owners of popular crates. The goal is to compromise maintainers' devices and accounts so the attackers can publish malware to crates.io.

The lure is a video call about something positive, such as a job, a project or a contract. During or after the call, the target is pushed to install a "missing audio codec" or to run a command, sometimes one already placed on their clipboard. The post says this style of attack is known to be used by the DPRK and links to research on the "Contagious Interview" campaign, but it does not claim the current activity is one connected campaign.

What's affected

This is a warning about people, not a vulnerable version. The post lists three related events:

• June 2026: a previous attack of this form targeted many prominent Rust developers.
• 20 August 2026: arrayref was briefly compromised through a similar attack. The Rust team found that arrayref@0.3.10, internment@0.8.7 and append-only-vec@0.1.9 had been republished to depend on a malicious crate, proc-macro1, whose build script downloaded a payload. Those versions were online for roughly 86 to 107 minutes before removal. Versions of proc-macro-en, aovine, arone, aronenao and tinymember were also deleted.
• 17 September 2026: the current warning.

The behavioural indicators the post gives are:

• Unsolicited video call offers tied to jobs, projects or contracts.
• Requests to install a codec or other software to "fix" the call.
• Instructions to run a command, including one placed on the clipboard.
• New company profiles with recently created but plausible LinkedIn presences.

No hashes, domains or account names were published.

How to check if you're exposed

If you maintain crates, list what you own and look at what was published recently:

# Crates your account owns (replace with your crates.io username)
curl -s -A "owner-check" \
  "https://crates.io/api/v1/crates?user_id=$(curl -s -A owner-check \
  https://crates.io/api/v1/users/YOUR_USERNAME | jq .user.id)&per_page=100" \
  | jq -r '.crates[] | "\(.name) \(.max_version) \(.updated_at)"'

Any version you don't remember publishing is an incident. Then review your API tokens at crates.io under Account Settings, and revoke any you can't tie to a current machine or CI job.

If you consume crates, confirm you never resolved the August versions:

grep -nE 'name = "(arrayref|internment|append-only-vec|proc-macro1|proc-macro-en|aovine|arone|aronenao|tinymember)"' -A1 Cargo.lock

# Also search the local cargo cache, as the Rust team suggested
find ~/.cargo/registry/cache -name 'arrayref-0.3.10.crate' \
  -o -name 'internment-0.8.7.crate' \
  -o -name 'append-only-vec-0.1.9.crate' \
  -o -name 'proc-macro1-*.crate'

A hit in the cache means a build on that machine downloaded the version, and its build script may have run.

What to do now

1. Run calls on your own terms. The post advises holding calls with new contacts on platforms you already trust, ideally by setting up the call yourself.
2. Never install software or paste commands at a stranger's request, even if it looks like a routine codec or "diagnostic" step. Nothing a legitimate interviewer needs requires it.
3. Check your accounts. Confirm MFA is on for GitHub and crates.io, and look for logins you don't recognise where the platform shows them.
4. Reduce what a stolen laptop can publish. Keep long-lived crates.io tokens off your daily machine. Publishing from CI with scoped, short-lived credentials means a compromised workstation can't push a release on its own.
5. Report anything suspicious. Use help@crates.io for crates.io account issues and security@rust-lang.org for everything else.
6. For consumers, commit Cargo.lock and review new versions of small, widely used crates before they reach your build. A patch release that adds a new dependency, as arrayref@0.3.10 did, is the signal worth catching.

Why it matters

Registries have spent years hardening publishing: 2FA, scoped tokens, trusted publishing. Those controls protect the account, but they cannot help much once the attacker is running code on the maintainer's own laptop. The arrayref incident shows how fast that turns into a release. A crate that many projects depend on picked up a malicious dependency and was live for well over an hour.

For consumers, the lesson is that a familiar name and a familiar maintainer are not a guarantee. The useful checks are the boring ones: lockfiles, a pause before adopting brand new versions, and a look at what changed in the dependency tree, not just the version number.

Try it yourself

Take one Rust service and diff its dependency tree between two recent lockfile commits. Note every crate that gained a new dependency in a patch release. For each one, check the crate's repository for a matching commit and tag. If a release has no matching source change, that's the pattern the arrayref attack produced.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Rust Blog: Be alert, targeted attacks on prominent Rustaceans (17 September 2026)
• Rust Blog: Supply chain attack on arrayref (20 August 2026)