What happened
On August 20, 2026 at 07:15 UTC, the Rust Security Response Team received a report that proc-macro1 was malicious and verified that its build script downloaded a payload. The three poisoned releases were published between 07:15:00 and 07:37:49 UTC on August 20, 2026 and were deleted by 09:25:24 UTC. Malicious releases were arrayref 0.3.10, internment 0.8.7 and append-only-vec 0.1.9; any version of proc-macro1, proc-macro-en, aovine, arone, aronenao or tinymember requires investigation.
A Cargo build that resolved any affected release executed the proc-macro1 build.rs payload without calling the affected crate’s API. The affected libraries retained otherwise legitimate-looking source, while proc-macro1 imitated proc-macro2 and performed the malicious build-time work. Attribution posture: The Rust Security Response Team attributes the publication to a likely compromise of the maintainer’s computer or credentials and does not name a threat actor.
StepSecurity lists 23.254.165.112:9089 as the payload host, 23.254.165.112:443 as command-and-control, and 23.254.167.107 plus 23.254.167.216 as additional observed infrastructure; hwsrv-798836.hostwindsdns.com is also named. Build-stage artefacts include /tmp/rust-setup on Unix and rust-setup.ps1 plus rust-setup-launch.vbs in the Windows temporary directory; reported Linux persistence includes $HOME/.config/AzureKits, $HOME/.config/ServiceKit, MonoService, MonoXpc and a systemd service.
The SHA-256 values published for arrayref 0.3.10 and proc-macro1 1.0.107 are 25ad700976873c76af785cb99b33c48db7df8b81f21d1e9e06b3676b9a9373ae and 61198155da51b838772eecf5bfaac6cbc4dcc388dccc56658fc28a8e831b34d4. The cited sources did not publish recoverable checksums for internment 0.8.7, append-only-vec 0.1.9 or proc-macro-en. The Rust Security Response Team recommends searching ~/.cargo/registry/cache for arrayref-0.3.10.crate, internment-0.8.7.crate, append-only-vec-0.1.9.crate and every version of the deleted attacker-controlled or associated crates.
Why this matters now
The malicious code executed during compilation, so application runtime telemetry and conventional vulnerability scanning are insufficient. A successful build could expose developer credentials, CI secrets, cloud tokens, package-publishing credentials or signing material before the resulting application ever ran. Ephemeral runners do not eliminate that exposure: a destroyed runner may already have transmitted secrets available to its job.
The short registry window reduces broad exposure but does not close the incident. Cargo lockfiles, registry caches, vendored dependencies and prebuilt CI images can preserve deleted artefacts. Organisations therefore need evidence of what resolved and what built, not reassurance that crates.io removed the versions. The event also demonstrates that a legitimate maintainer identity and successful test suite do not prove dependency provenance.
The decision for security leaders
Treat a matching build as an endpoint and identity incident, not a software-composition finding. The payload ran with the build user’s privileges; response scope must therefore include developer browsers, SSH material, cloud credentials, package tokens, code-signing keys and every secret mounted into the relevant CI job. Assign incident response ownership before deleting caches or recycling runners that contain evidence.
Require the application-security and platform teams to reconstruct dependency resolution from committed lockfiles, build logs, registry caches and vendored trees. Pin known-clean releases and rebuild on trusted infrastructure only after credential containment. The long-term control decision is whether build scripts may make unrestricted network connections and whether publisher identity, lockfile review and dependency provenance are enforced before privileged builds.
Evidence of closure
- Dependency inventory records no affected versions or links each hit to an approved incident case.
- CI logs establish whether affected dependencies were compiled during the exposure window.
- Endpoint and network review documents the disposition of every published indicator.
- Credential-rotation records cover all secrets reachable from confirmed build contexts caches, CI/CD logs and endpoints immediately and then begin rotating secrets and rebuilding from trusted runners.
The Security.io assessment
The registry response was rapid, and the malicious releases were available for less than two hours. That limits exposure but does not make it negligible: popular low-level crates can enter many dependency trees, and automated pipelines may resolve updates immediately. Download counts are not victim counts, while absence from the live registry is not evidence that local caches or previously produced artefacts are clean.
The decisive evidence is whether a bad version was resolved and compiled. A lockfile hit establishes dependency exposure; a cache hit shows retrieval; a build log or endpoint artefact establishes execution risk; matching egress or persistence materially strengthens a compromise conclusion. Closure should follow that evidence ladder rather than a blanket declaration that every organisation using Rust was affected.
Questions for the morning meeting
- Did any developer workstation, CI runner or release host resolve the affected crates during the exposure window?
- Which credentials, signing material or cloud roles were accessible to each potentially affected build?
- Are deleted crates retained in shared caches, vendored trees or container images?
- Can software releases be reproduced from pinned dependencies on newly trusted runners?