Back to blog

AUR and npm Supply Chain Attacks: How to Protect Yourself

securitysupply-chainarch-linuxnpm

Open-source software depends on trust. When you install a package, you trust its author, its maintainers, and every package it depends on. In 2026 several campaigns showed how attackers exploit that chain: hijacking abandoned packages, phishing maintainers and slipping malicious code into build scripts. This article summarises what was reported and, more usefully, the practical habits that make you harder to hit.

The details below come from security vendors and advisories, which are not always independent. Specific counts and package versions vary between reports, so verify them against primary sources before acting on any one number.

The AUR campaign

The Arch User Repository, or AUR, is a community collection of build recipes for software that is not in Arch Linux's official repositories. In June 2026, researchers reported a campaign dubbed Atomic Arch in which attackers took over orphaned AUR packages, meaning ones whose maintainers had abandoned them, and modified their build scripts. The altered scripts pulled in a malicious npm dependency that delivered a credential-stealing program written in Rust and, where the attackers gained root access, an eBPF rootkit. Reports put the number of affected packages at over 400. The official Arch repositories were not affected.

Maintainer account takeovers on npm

Meanwhile the npm ecosystem faced repeated account takeovers. The Mini Shai-Hulud campaign hit packages in May 2026 through a compromised maintainer account. In another incident, 144 Mastra packages were reported compromised through phishing of a maintainer. Sonatype's index for the second quarter of 2026 reported that npm accounted for about 96.6% of malicious packages that quarter, and a later campaign was tracked across hundreds of packages. The attackers are targeting people, because compromising one trusted publisher can reach thousands of downstream projects.

Why these attacks work

  • Abandoned packages keep their reputation. Users and scripts continue to trust a name, even after the original author is gone.
  • Install scripts run code automatically. A build script or install hook executes with your permissions.
  • Transitive dependencies hide risk. You trust one package, which trusts dozens more.
  • Maintainers are busy volunteers, and phishing against them is effective.

Habits for AUR users

  • Read the PKGBUILD before you build, and read it again when an update changes it.
  • Be suspicious when a package you use is adopted by a new maintainer, especially one with no history.
  • Prefer official repository packages and Flatpaks where they exist.
  • Never run an AUR helper in a way that skips the review step.

Habits for developers using npm

  • Commit your lockfile and install from it, so versions change only when you decide.
  • Consider disabling automatic install scripts for packages that do not need them.
  • Delay adopting brand-new releases for a short period so the community can spot problems first.
  • Run builds in containers or throwaway environments that hold no personal credentials.

If you publish packages

Protect your account with phishing-resistant two-factor authentication such as a hardware key, rather than text-message codes. Use scoped, short-lived publishing tokens instead of long-lived ones, and prefer publishing from automated pipelines with restricted permissions. If you no longer maintain a package, say so, transfer it responsibly, or mark it deprecated instead of leaving it orphaned.

If you think you were affected

Advisories for these incidents recommend treating affected systems as compromised: rotate every credential that was present, clear package caches, remove installed dependencies and roll back to known-good versions. For systems where a rootkit may have been installed, reinstalling is safer than trying to clean the machine. Monitor your accounts for unusual activity afterwards.

The bigger picture

No tool eliminates supply chain risk, but small, consistent habits reduce it a great deal. Reviewing build scripts, pinning versions and protecting maintainer accounts all raise the cost for attackers, who generally go after the easiest targets first.

Sources