June 13 incident update: 400+ AUR packages
The latest security reporting describes a broad AUR compromise involving more than 400 community packages whose build scripts were allegedly rewritten to deploy a Rust-based infostealer and, where privileges allowed, eBPF-style rootkit persistence. For Omellody readers, the practical takeaway is not that every Arch workstation is compromised; it is that any machine that built or installed one of the affected AUR recipes during the exposure window should be treated as a developer-workstation incident until the package diff, install logs, and credential exposure are reviewed.
Prioritize machines that had SSH keys, browser sessions, cloud CLIs, password manager sessions, package publishing tokens, or production VPN access available at build time. A malicious PKGBUILD or install hook can harvest local secrets before a user notices anything unusual, and root-level execution can make post-compromise inspection unreliable. If the affected host had sudo access during the install, rebuild from trusted media is the safer default; targeted cleanup is only reasonable when the build happened inside an isolated container with no secrets mounted.
For teams, create a quick inventory of AUR packages installed across laptops and CI images, compare package timestamps against the reported incident window, and pause automated AUR rebuild jobs until each recipe is reviewed. Rotate Git, SSH, registry, CI/CD, cloud, and password manager sessions from a clean device, then invalidate old deploy keys and audit recent repository pushes. This incident also strengthens the case for clean build containers, allow-listed package sources, and a standing Linux workstation recovery runbook rather than ad hoc cleanup after each supply-chain alert.
Immediate triage
Arch User Repository packages are community-maintained build recipes. That flexibility is useful, but it also means a hijacked maintainer account, poisoned source URL, or malicious install script can run code during build or install. Treat any unexpected post-install behavior as a workstation incident until proven otherwise.
- Disconnect from corporate VPNs, admin panels, and production SSH sessions.
- Save shell history, pacman logs, AUR helper logs, systemd journal snippets, and the exact package version.
- Do not keep entering passwords on the host while you investigate.
- Compare the PKGBUILD, install files, checksums, and source URLs with trusted package history.
- If the package used sudo, changed system services, loaded modules, or touched boot files, plan a clean rebuild.
Package verification table
| Check | What to inspect | Risk signal | Action |
|---|---|---|---|
| PKGBUILD diff | build(), package(), prepare(), source array | curl pipe to shell, obfuscated commands, new binary blob | Do not install; preserve copy for reporting |
| Install hooks | .install scripts, post_install, post_upgrade | User creation, sudoers edits, systemd enablement | Audit persistence and rebuild if root ran it |
| Source integrity | Checksums, tags, release assets, maintainer change | Checksum drift or new unreviewed host | Pin known-good source or wait for maintainer fix |
| Runtime behavior | Network connections, new timers, loaded modules | Unexpected outbound traffic or persistence | Isolate host and rotate credentials |
eBPF and persistence checks
A malicious package does not need a flashy payload to be dangerous. A developer workstation often holds SSH keys, browser sessions, cloud tokens, package registry credentials, and password manager sessions. If the package gained elevated privileges, check the common persistence layer before trusting the machine again.
- List enabled systemd services and timers added near the install time.
- Check shell startup files, cron entries, sudoers snippets, SSH authorized keys, and pacman hooks.
- Inspect loaded kernel modules and BPF programs with trusted tools from a clean environment.
- Review unexpected listeners, outbound connections, and DNS changes.
- Prefer a clean reinstall when the host handled production keys or privileged cloud access.
Credential rotation order
Rotate from a clean device, not from the potentially compromised Arch host. Start with keys that let an attacker expand access.
- SSH keys and Git signing keys used on the workstation.
- GitHub, GitLab, package registry, CI/CD, and cloud API tokens.
- Password manager account sessions and recovery methods.
- Email, banking, crypto, domain registrar, and hosting accounts.
- Browser sync, messaging, and file-sync sessions.
Rebuild decision card
Clean rebuild recommended when: the package ran as root, changed systemd units, added kernel/eBPF components, touched SSH files, modified sudoers, or ran while sensitive sessions were active.
Targeted cleanup may be acceptable when: the package never installed, you only reviewed the PKGBUILD, or the build ran in a disposable clean container with no secrets mounted.
Best next step: preserve evidence first, then rebuild from trusted media and restore only data files you can inspect.
Source snapshot
This checklist was prepared from defensive security practice for Linux package incidents as of June 13, 2026. It does not rely on copying external repository content. When handling a real incident, compare against the current Arch Linux news feed, AUR package comments, upstream maintainer advisories, and your own package manager logs.
Related guides
Frequently asked questions
What should I do first after a suspicious AUR install?
Disconnect from sensitive networks, preserve logs, stop typing secrets, and verify the PKGBUILD, install scripts, source URLs, checksums, and maintainer history.
Can an AUR package install an eBPF rootkit?
If malicious code gets elevated privileges, it can attempt kernel-level or eBPF-based persistence. Inspect loaded programs and rebuild if trust is low.
Should I reinstall Arch after a package hijack?
Yes if root-level scripts ran, persistence changed, secrets were present, or you cannot prove what the package did.
Which credentials should I rotate?
Rotate SSH keys, Git tokens, cloud API keys, package registry tokens, password manager sessions, and any passwords typed after the suspicious install.
How do I reduce future AUR risk?
Read PKGBUILDs, avoid abandoned packages, use clean build containers, prefer official repositories for critical tools, and keep reproducible backups.