AUR packages compromised with Infostealer and Rootkit

Scope and nature of the compromise

• Around ~400 AUR packages were taken over, mostly by adopting orphaned packages and injecting malicious build steps.
• Payload initially used npm install atomic-lockfile ... during post_install; later variants switched tooling (e.g., bun) to evade simple indicators.
• Campaign has been ongoing, with fresh malicious commits still appearing; not limited to a single incident window.

Detection and “Am I owned?”

• Multiple scripts / one‑liners shared to:
  • Cross‑check installed AUR packages against lists of known compromised ones.
  • Distinguish “installed but never updated during attack window” vs “updated and likely infected.”
• Key nuance: just having an affected package installed is not enough; you generally needed to update it during the malicious period.
• Links to preliminary malware analyses and rootkit check ideas were shared; effectiveness of generic tools (e.g., rkhunter) for this specific BPF rootkit is unclear.

AUR trust model and its limits

• Strong reminder: AUR is explicitly “user‑produced, at your own risk,” closer to a pastebin than a vetted repo.
• Many argue you must:
  • Read every PKGBUILD before installing.
  • Review diffs on every update, including patches and external sources.
• Others say this is unrealistic at scale and comparable to expecting everyone to fully read EULAs.

Orphaned packages and adoption policy

• Core attack vector: mass adoption of orphaned packages (there are many thousands), then adding malicious steps.
• Several call the current adoption model “broken” and suggest:
  • Forcing new submissions instead of silent takeovers.
  • Purging old orphans.
  • Prominent warnings when maintainership changes.
• Some propose username‑scoped package names to make ownership clearer.

User practices and mitigations

• Many recommend:
  • Sticking to official repos where possible; keeping AUR usage minimal.
  • Avoiding AUR helpers or at least using them only with manual PKGBUILD diff review.
  • Being wary of AUR packages that themselves depend on other AUR packages, large patch sets, or extra network‑downloading steps.
  • Running risky software in VMs/containers or separate QEMU VMs for different roles (work vs finance).
• Tools like traur and other scanners can flag suspicious patterns (e.g., orphan takeovers), but are not guarantees.

Role of npm and broader supply‑chain risk

• The malicious code was distributed via npm (and later other JS tooling), reinforcing perceptions of the JS ecosystem as a frequent supply‑chain vector.
• Several note this is not unique to AUR: PyPI, npm, cargo, browser extensions, Flatpak/Flathub etc. all share similar systemic risks.

Arch’s response and communication

• Some criticize delayed or minimal official messaging and argue AUR should have been temporarily “quarantined” with clear warnings.
• Others counter that:
  • AUR has always been explicitly unvetted.
  • Infrastructure is volunteer‑run; expectations of “enterprise‑grade” incident response are unrealistic.
• Eventually an official Arch news item acknowledged the incident; maintainers are processing delete/orphan requests.

Future safeguards and automation

• Suggested improvements:
  • Warnings in helpers for recent owner changes, orphan adoptions, and unusual downloads (e.g., new npm/curl usage).
  • Optional automated scanning (including LLM‑based review) to flag suspicious PKGBUILD changes, while recognizing prompt‑injection and false‑sense‑of‑security risks.
  • Stronger sandboxing/VM isolation and broader adoption of supply‑chain frameworks like SLSA.
• Some see this as “effectively the end of the current AUR model”; others view it as a serious but unsurprising incident that reaffirms long‑standing caveats rather than invalidating AUR entirely.