THREAT BRIEFING · 22.10.2026 DEENFRES

Security Glossary

Arrayref: Malware enters the build

By Alec Chizhik · August 22, 2026 · 7 min read

On 20 August 2026, arrayref 0.3.10 appeared on crates.io, pulling in the proc-macro1 dependency. Its build script downloaded and launched an architecture-specific payload during compilation. The registry removed the version from the index after around 86 minutes; Nextron Systems had reported the incident.

Key takeaways

  • arrayref 0.3.10 was on crates.io for 86 minutes. RustSec lists the case as RUSTSEC-2026-0260. The advisory reports 2,285 downloads of the affected version.
  • The malicious logic was in proc-macro1’s build script. Cargo builds declared dependencies even when the library code does not use them.
  • crates.io removed the versions, and the account is suspended. Teams are checking lockfiles and Cargo caches and assessing build hosts used during the exposure window.

Related: Five metrics the supervisory board actually understands  ·  Which controls must survive tool consolidation

The malicious chain began in the manifest

The affected release was arrayref 0.3.10. The crate is a lightweight utility library for array references. The malicious logic sat outside this library code and arrived through the newly declared proc-macro1 dependency.

Cargo resolves and builds dependencies from the manifest even when the project’s code does not call them. This explains the incident: an apparently unchanged utility library opened the malicious path once its manifest listed the additional dependency.

In its secondary analysis, SafeDep describes proc-macro1 as a typosquat targeting a family of names associated with procedural macros. RustSec lists the case as RUSTSEC-2026-0260. According to the advisory, there is no patched successor to 0.3.10. It lists versions 0.3.5 to 0.3.9 as unaffected.

The build became the execution point

According to Rust Security Response, proc-macro1’s build script downloaded and launched an architecture-specific payload during compilation. The attack did not depend on a runtime import in the finished binary. It depended on the build host, network access and the build process’s permissions.

SafeDep’s secondary analysis describes the same sequence: a build dependency, a network download and local artifacts. According to the Rust project, execution took place in the build script.

The investigation identified paths in temporary directories as indicators. On Unix-like systems, /tmp/rust-setup appears. On Windows, rust-setup.ps1 and rust-setup-launch.vbs appear in %TEMP%. These paths identify where to investigate. A path alone does not prove infection.

Tenable also catalogs the issue as CVE-2026-77651. The Rust project sources reviewed and the RustSec entry do not mention this number.

Definition · Build script

Cargo runs a dependency’s build script during compilation once the dependency is listed in the manifest. Whether the library code later calls that dependency is irrelevant.

Three crates, one compromised release process

Rust Security Response names three affected releases: arrayref 0.3.10, internment 0.8.7 and append-only-vec 0.1.9. RustSec separately records append-only-vec 0.1.9 as RUSTSEC-2026-0262. These three names represent compromised releases of established crates.

These are distinct from the deleted malicious dependencies proc-macro1, proc-macro-en, aovine, arone, aronenao and tinymember. Those dependencies served to download and execute malicious code rather than act as legitimate successors.

According to Rust Security Response, the arrayref account’s maintainer likely fell victim to a compromised machine or compromised credentials. The account was suspended as a precaution. This concerns control of the account and does not automatically implicate every downstream project.

A third-party analysis by Wiz describes overlaps with previously observed campaigns; this establishes neither attribution nor widespread infection of Rust projects.

Caches and lockfiles reveal what is present

The registry figure measures distribution rather than damage. The current advisory reports 2,285 downloads of arrayref 0.3.10, less than ten percent of total download traffic to date. The figure counts registry fetches. It does not count executed build scripts or prove that everyone who downloaded the crate was compromised.

The lockfile is the first place to check whether a project built the affected version. It records the version actually resolved. The local Cargo cache should also be checked against the same list: arrayref 0.3.10, append-only-vec 0.1.9, internment 0.8.7, plus proc-macro1, proc-macro-en, aovine, arone, aronenao and tinymember.

A cache hit indicates local files without necessarily proving that build logic ran. An arrayref 0.3.10 lockfile entry shows that dependency resolution selected this version. Both findings warrant assessment of the build host.

Cargo inventory checks

  • ✓Check the lockfile for arrayref 0.3.10, internment 0.8.7 and append-only-vec 0.1.9
  • ✓Search the Cargo cache for affected crates and deleted dependencies
  • ✓Include the build host, CI secrets and generated artifacts in the forensic assessment

The 86-minute window does not close the case

The exposure window on crates.io was short. The release was available there for around 86 minutes. The report reached the Rust project on 20 August 2026 at 07:15 UTC. Removal from the index ends public availability; local caches, CI runners and previously generated artifacts remain relevant.

Anyone who built during the relevant window should assess the affected hosts forensically. A build using the listed versions should trigger rotation of credentials, tokens, CI secrets and signing keys under the internal incident process, followed by rebuilding artifacts from a clean environment.

Older versions up to 0.3.9 are listed as unaffected; according to the advisory, there is no patched 0.3.10. Anyone who downloaded the malicious version should revert to a version listed as unaffected while checking the host and secrets.

Sources: Rust Security Response dated 20 August 2026, last updated on 21 August 2026; RustSec RUSTSEC-2026-0260 and RUSTSEC-2026-0262; technical analysis by SafeDep and Wiz.

Frequently asked questions

Each question is locked. Tap to unlock the answer.

Which version of arrayref is affected?

RustSec identifies arrayref 0.3.10. The advisory lists the crate as unaffected up to 0.3.9. The local lockfile determines which version was actually built.

Is updating the project itself enough?

An update alone does not resolve the incident question. The cache, lockfile and build host must be checked together because the malicious logic ran during the build.

Which other crates should we check?

Rust names append-only-vec 0.1.9 and internment 0.8.7, plus the deleted names proc-macro1, proc-macro-en, aovine, arone, aronenao and tinymember.

What should we do about an affected build host?

The host undergoes forensic assessment. Depending on the findings, credentials, CI secrets and signing keys are rotated, and artifacts are rebuilt from a clean environment.

Is there evidence of a widespread attack on all Rust projects?

No. The registry reports 2,285 downloads of the affected arrayref version. This figure does not count executed malicious scripts or establish that all users were compromised.

Editor’s Picks

▣Editor’s PickMicrosoft Teams: Android Path Traversal Runs Attacker Code▣Editor’s PickWhat Is a Supply-Chain Attack? Definition and Defense▣Editor’s PickCI/CD Published AsyncAPI Botnet Loader

More from the MBF Media Network

▣cloudmagazinOpenAI Pulls the Plug on Cursor: Your Own Key as Plan B▣MyBusinessFutureWindows 11 limits what AI agents can access▣Digital ChiefsAI Shifts Development into Review Work. Who Owns Sign-off?

Image source: AI-generated (August 2026)

Translated from the German original using artificial intelligence. The German version is authoritative.

Further reading

A magazine by Evernine Media GmbH