The short answer
On August 20, 2026, attackers compromised the publishing credentials of three Rust crate maintainers and released poisoned versions of arrayref (0.3.10), internment (0.8.7), and append-only-vec (0.1.9) to crates.io. Each poisoned crate injected a typosquatted dependency — proc-macro1 (the legitimate crate is proc-macro2) — whose build script downloaded and executed a remote binary during cargo build. Wiz researchers found significant infrastructure overlap with prior DPRK campaigns targeting npm. The crates were pulled within 86–107 minutes, but any CI or developer machine that compiled a project with a freshly resolved lockfile during that window should be treated as potentially compromised.
What happened: the attack in detail
At some point on August 20, 2026, attackers gained access to the publishing credentials of the maintainers of three popular Rust crates. The method of credential compromise has not been confirmed publicly; the Rust Security Response Team stated that the most likely explanation is that the developers’ machines or their crates.io API tokens were compromised, not that the developers themselves acted maliciously.
The attackers published new patch versions of each crate: arrayref@0.3.10, internment@0.8.7, and append-only-vec@0.1.9. Each new version added a single new dependency — proc-macro1 — to its Cargo.toml. The legitimate crate widely used in the ecosystem is proc-macro2; the typosquat is designed to slip past a quick visual scan of a diff. Critically, proc-macro1 was the first dependency arrayref had ever declared in its ten-year publication history, which is a signal that automated dependency monitoring tools should flag.
The Rust Security Response Team identified the malicious releases, yanked all three versions from crates.io, and locked the affected maintainer accounts within 86 to 107 minutes of the poisoned packages appearing. The official Rust Blog published a notice the same day. A supply chain security audit of your dependency graph and CI pipeline is the most reliable way to verify you were not affected during this window.
How the build-time payload worked
Rust’s build system, Cargo, supports build scripts — a build.rs file at the crate root that executes at compile time, before the crate’s own code is compiled. Build scripts have full network and filesystem access on the build host. They are commonly used for legitimate purposes: generating code from protobuf schemas, compiling C libraries, or querying environment variables. They are also a well-known attack surface; this incident is a textbook exploitation of that surface.
The malicious proc-macro1 build script reconstructed a command-and-control server address from Base64-obfuscated strings, disabled TLS certificate verification, and issued an HTTP request to download a platform-specific binary. The binary was then executed directly in the build environment. On a typical CI runner, that environment has access to cloud provider metadata endpoints, cached credentials, build secrets, and environment variables holding tokens for registries, artifact stores, and deployment targets.
The payload executed on build, not on run. A project that had arrayref as a transitive dependency — thousands of crates list it as a direct dependency — and that ran cargo build, cargo test, or cargo check against a lockfile that resolved to the poisoned version during the 86–107 minute window would have triggered the payload without the developer ever invoking the malicious crate’s own functions.
Scale: why arrayref is a high-value target
arrayref is not an obscure package. It provides a single macro — array_ref! — for safely slicing fixed-size arrays from byte slices. That primitive is used extensively in cryptographic libraries, binary serialization, and embedded systems code written in Rust. At the time of the attack:
- 245 million all-time downloads on crates.io
- 53.7 million downloads in the preceding 90 days
- 403 crates list arrayref as a direct dependency
- Present in approximately 35% of all Rust development environments, and roughly 75% of environments where Rust is used
A 107-minute exposure window against a crate at that download velocity means a meaningful number of builds worldwide touched the poisoned version before it was pulled. Projects that pin dependencies in lockfiles are not automatically protected: Cargo resolves to the latest patch version satisfying a constraint when no lock exists or when cargo update is run, and CI pipelines that regenerate lockfiles on each run are particularly exposed.
DPRK attribution and the wider pattern
Wiz reported significant infrastructure overlap between the command-and-control servers used in this attack and servers previously linked to DPRK-attributed campaigns against the npm and JavaScript ecosystems. SecurityWeek independently covered the attribution link. The Rust Security Response Team’s official notice did not attribute the attack, focusing instead on the technical facts and remediation steps.
The attribution, if accurate, fits an established pattern. North Korean threat actors have repeatedly targeted developer ecosystems — npm, PyPI, and GitHub Actions — with the goal of reaching the CI environments and cloud credentials of the organizations that build on these open-source foundations. Rust’s use in systems software, cryptographic libraries, and cloud infrastructure tooling makes it a high-value target: a build that executes on a runner with AWS or GCP metadata access is significantly more valuable than one that runs on an isolated workstation.
This attack also follows a DPRK playbook of targeting maintainer credentials rather than the package registry itself. Stealing or phishing an API token is lower effort than finding a registry vulnerability, and the blast radius is bounded by the target crate’s download count rather than the entire registry.
What it means for US & EU software teams
Build-time execution is not a theoretical risk. The npm ecosystem has seen build-script attacks before; this confirms the Rust ecosystem is now actively targeted at the same level. Any language with a build-time execution step — npm postinstall, Python setup.py, Rust build.rs — carries this risk. Teams that have audited their npm supply chain but not their Rust one have an asymmetric blind spot.
Lockfile hygiene is a defense, not a guarantee. A committed Cargo.lock that pins exact versions protects against future resolution to a yanked version — but only if the lock predates the poisoned release. Pipelines that run cargo update or regenerate the lockfile at build time would have pulled the new version during the exposure window. Post-incident, check Cargo.lock history to confirm the version your CI resolved to on August 20.
For FinTech and HealthTech teams, CI runners are a compliance boundary. A runner with access to PCI-scoped payment service credentials, HIPAA-covered API tokens, or GDPR-regulated data store keys is a compliance incident when compromised by malware — regardless of whether any data was exfiltrated. Incident response obligations may apply even if forensics later show the payload did nothing destructive on that particular machine.
EU NIS2 and DORA both require supply chain security controls. Article 21(2)(f) of NIS2 and Article 28 of DORA explicitly require measures covering supply chain security, including the software components used in production and development. A build-time compromise of a transitive dependency during CI is exactly the scenario these frameworks are designed to cover, and regulators are increasingly asking for documented dependency monitoring practices during audits.
Rust in your stack? Audit your supply chain before the next incident.
Our engineers conduct penetration testing and security audits that cover Rust and polyglot dependency graphs, CI runner exposure, secret sprawl in build environments, and supply chain policy enforcement with cargo-deny and equivalent tools. We deliver a remediation roadmap in two to four weeks, mapped to NIS2 and DORA requirements where relevant.
What dev teams should do now
| Action | Timeline | Notes |
|---|---|---|
Check Cargo.lock for arrayref@0.3.10, internment@0.8.7, or append-only-vec@0.1.9 | Today | If any of these appear in lock history on August 20, treat the build environment as potentially compromised and proceed to the next steps |
| Review CI build logs from August 20 for anomalous network connections | Today | Look for outbound HTTP/HTTPS requests during the cargo build phase, especially to unfamiliar hosts; check for unexpected subprocess invocations |
| Rotate all secrets accessible to affected build runners | This week | API keys, cloud provider credentials, container registry tokens, deployment keys, database passwords — everything available via environment variables or metadata endpoints on the runner |
Add cargo-deny to your CI pipeline | This sprint | cargo-deny can block builds if new transitive dependencies appear unexpectedly, if a crate has never had dependencies before and suddenly gains one, or if a license or advisory constraint is violated |
Pin Cargo.lock in all CI pipelines and commit it to version control | This sprint | Committed lockfiles prevent silent version resolution changes; cargo build --locked fails if the lockfile would change, making accidental pulls of new versions visible |
| Audit all Rust crates for build.rs files and assess their legitimacy | Next sprint | Inventory which of your direct and transitive dependencies include build scripts; flag any that perform network requests and verify these are intentional and scoped |
Sources: Rust Blog — Supply chain attack on arrayref (The Rust Programming Language Blog, August 20, 2026); The Hacker News — Rust Supply Chain Attack Puts Build-Time Malware in Crates with 245 Million Downloads (The Hacker News, August 2026); SecurityWeek — Rust Supply Chain Attack Linked to North Korean Hackers (SecurityWeek, August 2026); Wiz Blog — Rust Supply Chain Attack on arrayref: Significant Overlap with DPRK Campaigns (Wiz, August 2026).
FAQ
Which Rust crates were poisoned in the August 2026 supply chain attack?
Three crates were compromised: arrayref@0.3.10, internment@0.8.7, and append-only-vec@0.1.9. All three were published by attackers who compromised the maintainers’ publishing credentials on August 20, 2026. The malicious versions added a typosquatted dependency called proc-macro1 (the legitimate crate is proc-macro2) whose build script downloaded and executed a remote payload whenever a developer ran cargo build.
How did the malware execute — did you need to run the malicious crate’s code directly?
No. The payload ran during the build phase, not at runtime. Rust’s Cargo build system executes build.rs scripts when compiling dependencies. The attacker’s proc-macro1 crate included a build script that reconstructed a C2 URL from Base64-obfuscated data, disabled TLS verification, and downloaded a platform-specific binary. Running cargo build on any project that depended on the poisoned crate versions was sufficient to trigger execution — no deployment or runtime invocation needed.
How quickly were the malicious crates removed?
The Rust Security Response Team removed the malicious versions within 86 to 107 minutes of publication. The team also locked the affected maintainer accounts. However, any developer who ran cargo build during that window on a project with a lockfile that resolved to the malicious versions would already have executed the payload on their machine or CI runner.
Who is behind the attack?
Wiz researchers reported significant infrastructure overlap between the attack and prior DPRK-linked (North Korean) campaigns targeting the npm and JavaScript ecosystems. SecurityWeek independently reported the DPRK attribution link. The Rust Security Response Team stated the legitimate developers’ machines or publishing credentials were likely compromised rather than the maintainers acting maliciously.
What should Rust dev teams do right now?
Four immediate actions: (1) Check your Cargo.lock for arrayref versions 0.3.10, internment 0.8.7, or append-only-vec 0.1.9 — if present in build history from August 20, treat those builds as potentially compromised. (2) Review CI build logs from August 20 for any anomalous network connections or subprocesses spawned during cargo build. (3) Rotate secrets (API keys, tokens, cloud credentials) that were accessible on any machine or runner that built an affected project during the exposure window. (4) Enable cargo-deny or a similar supply chain policy tool to flag new transitive dependencies introduced by crates that have no prior dependency history.