← All postsAugust 24, 2026

A Ten-Year-Old Code Library Got Hijacked in 86 Minutes

On August 20, a widely used open-source code library called arrayref — part of the Rust programming language ecosystem, with over 245 million downloads over its lifetime — was quietly hijacked. Whoever compromised the maintainer's account (the Rust project believes it was a stolen credential or infected machine, not the maintainer acting badly) pushed out a new version that added a single new dependency, something the library hadn't done in ten years. That dependency's job, once downloaded during a normal build, was to fetch and run malware on the developer's machine. Two smaller libraries from the same maintainer got the same treatment. The Rust security team caught it and pulled all three within roughly 90 minutes to under two hours of publication.

Why a 90-minute window still matters

The fast response is the good news here, and it's worth crediting — the Rust project's security team moved quickly once someone flagged it. But "fast" doesn't mean "no exposure." Any developer who happened to build a project pulling in that library during that window ran the malicious code automatically, just by compiling their software. That's the uncomfortable part of how modern software gets built: almost nothing is written entirely from scratch anymore. Every website, app, or internal tool is assembled from dozens or hundreds of smaller, often free, community-maintained building blocks — and a compromise several layers deep in that stack can reach the final product without anyone touching your code directly.

What this means if you don't write software yourself

Most small business owners aren't personally choosing which code libraries their site or app depends on — a developer, agency, or platform is doing that on their behalf. That's fine; you shouldn't need to become a security analyst. But a few things are worth knowing:

  • "We didn't write any vulnerable code" isn't the same as "we're not exposed." Most real-world software risk today lives in dependencies, not in the code your team actually authored.
  • Ask whoever maintains your software how they track this. Do they know what libraries their build depends on, and do they get notified when one of them has a security problem? A shrug is a useful answer too — it tells you where the gap is.
  • Patching promptly matters more than picking "safe" tools. This kind of incident isn't really preventable by choosing better software up front; it's contained by having a process that reacts quickly when something goes wrong; speed is what turned this into a footnote instead of a headline.

None of this is a reason to distrust open-source software generally — it's the foundation of nearly everything running today, this incident included the system that caught and fixed it fast. It's a reason to make sure someone is actually watching that foundation on your behalf.

Sources: