Atomic Arch: 1,500+ AUR Packages Backdoored With an eBPF Rootkit and a Credential Stealer

The Arch User Repository is community plumbing rather than an official archive, and that is exactly what the attackers behind Atomic Arch exploited starting around June 11, 2026, when they began systematically claiming abandoned orphan packages through AUR's legitimate adoption flow and quietly editing the PKGBUILD scripts those packages shipped. The campaign was reverse engineered and named by Sonatype, with parallel reporting from SecurityWeek, Cybersecurity News, Latest Hacking News, and StepSecurity, while a community detection list is being maintained at github.com/lenucksi/aur-malware-check. An initial wave touched roughly 400 packages, a second wave on June 12 pushed the total past 1,500, and Arch Linux suspended new AUR account registrations while its security team audits the repository.

What makes the campaign worth studying is how mundane the access path was, because the attackers did not breach AUR infrastructure or steal a maintainer's password. They watched for packages flagged as orphaned, requested adoption through the same workflow any community contributor would use, and once AUR granted control they slipped a new dependency into the PKGBUILD that pulled a malicious npm package called atomic-lockfile at install time. The npm tarball bundled a Linux payload that combined an eBPF rootkit with a credential and token sweep, so a user running yay -S or paru -S on any affected package ended up executing kernel-level instrumentation as root during the build, as documented by Sonatype and corroborated by StepSecurity.

The blast radius reaches further than the Arch desktop crowd, because Manjaro, EndeavourOS, Garuda, and other Arch-based distributions all consume AUR through the same helper tools, and developer workstations and CI pipelines that install AUR packages non-interactively were the most exposed once the eBPF rootkit started hiding its own processes, files, and network traffic from userspace observation. The payload swept SSH private keys, GnuPG material, browser profile credentials, npm and PyPI tokens, GitHub and GitLab Personal Access Tokens, cloud credential files, and any .env reachable on the host, with Sonatype and Cybersecurity News noting that it specifically walked shell history and dotfile locations for the secrets developers leave around.

The detection and response gap

Every assumption a Linux endpoint team relies on for AUR builds was deliberately bypassed, and each one maps to a control that should have fired but did not:

• The maintainer was the maintainer on paper. AUR's adoption flow is intentionally low friction so the community can rescue abandoned packages, which means an attacker who waits for orphan flags can take legitimate control without tripping any takeover heuristic.
• PKGBUILD changes look like normal maintenance. A new dependency line added during a routine version bump is the kind of edit reviewers skim past, so the malicious atomic-lockfile import blended into ordinary churn.
• The npm staging point bypassed pacman scrutiny. Because the payload arrived as an npm dependency fetched during the build, anyone reviewing only the PKGBUILD source ahead of install would not have seen the eBPF rootkit or the stealer at all.
• eBPF runs below the EDR that defends most fleets. Once the rootkit loaded, it hooked syscalls and tc-bpf hooks to hide its own processes, sockets, and files from ps, ss, and any user-space sensor that asks the kernel politely, which is why endpoint agents reading /proc can be blind to it.
• The trigger ran as root. AUR helpers escalate during package build, so the credential sweep and the rootkit load both fired with full system privilege the moment the user accepted the install prompt.

Mapping the behavior to MITRE ATT&CK

Turning Atomic Arch into ATT&CK gives a blue team a concrete target to build detections against and then validate against the actual chain rather than the abstract idea of a supply-chain attack:

• T1195.002 Compromise Software Supply Chain: hijacking AUR maintainership through the legitimate orphan adoption flow and chaining a malicious npm dependency so distribution rides community trust rather than infrastructure compromise.
• T1546 Event Triggered Execution: the modified PKGBUILD as the trigger that runs the atomic-lockfile install hook during routine package installation.
• T1014 Rootkit and T1620 Reflective Code Loading: loading an eBPF program into the kernel to hide processes, files, and sockets from user-space tooling, with unit file persistence to survive reboots.
• T1552.001 Credentials In Files and T1555 Credentials from Password Stores: sweeping SSH keys, GnuPG material, browser stores, and dotfile secrets such as .env, ~/.aws/credentials, and Kubernetes kubeconfig.
• T1528 Steal Application Access Token: exfiltrating GitHub, GitLab, npm, PyPI, and cloud access tokens for downstream supply-chain pivots.
• T1071.001 Web Protocols: beaconing harvested secrets out over HTTPS so the egress blends with the traffic developer workstations generate all day.

Operationalizing a response

If any workstation, build server, or CI runner in your environment installed an AUR package between roughly June 10 and June 13, 2026, treat that host as compromised until you walk through the cleanup below, because an eBPF rootkit that hides its own footprint is not something you confirm clean by glancing at top:

1. Pull the community detection list at github.com/lenucksi/aur-malware-check and diff it against every AUR package installed since June 10 on every workstation, runner, and laptop in scope.
2. Remove atomic-lockfile and any confirmed malicious package, then run the rootkit scanner the Arch Linux security team is publishing alongside the audit, since eBPF artifacts will not show in a standard pacman query and your normal EDR may have been instrumented to lie.
3. Rotate every credential reachable from the affected host, including SSH and GnuPG keys, cloud access keys, GitHub and GitLab PATs, npm and PyPI publish tokens, Kubernetes service account tokens and kubeconfigs, and any .env or ~/.aws/credentials file the user touched.
4. Reimage the host where possible rather than relying on selective cleanup, because an eBPF rootkit with persistence hooks is exactly the kind of payload that earns a reinstall.
5. Tighten the trust boundary around AUR by pinning which helpers can run unattended, requiring human review of PKGBUILD diffs on packages whose maintainer changed in the last 30 days, and treating non-interactive AUR installs in CI as a privileged operation.

How BlueTeamAutomation closes the loop

Walking that response playbook by hand, host by host, after a rootkit is already resident is the slow path Atomic Arch is counting on. BlueTeamAutomation runs the full blue-team workflow against this class of Linux supply-chain compromise continuously and on hardware you control:

• BAS validation. BASzy emulates the Atomic Arch chain against your real fleet, an AUR-style install that pulls a malicious dependency, loads an eBPF program, and beacons harvested secrets, so you find which sensors miss kernel-level evasion while it is still a drill.
• EDR. On-device detection watches pacman, makepkg, and AUR helper child processes for combinations that should never co-occur, an npm fetch during a system package build, a bpf syscall from a build context, or a systemd unit written from inside a package install.
• SIEM correlation. AUR install events, kernel audit telemetry, GitHub and GitLab token usage, npm registry pulls, and cloud control plane reads collapse into one timeline, so a freshly adopted AUR package plus a bpf load plus an unexpected token use becomes one alert rather than three orphan signals.
• SOAR response. Automated playbooks isolate the affected host, revoke and rotate the cloud, source control, and registry tokens reachable from it, queue the reimage, and open the incident inside the window where a Linux rootkit is still contained.
• Compliance evidence. Every validation, detection, response, and rotation event is captured as audit-ready evidence for SOC 2, ISO 27001, and the supply-chain attestation expectations your customers and regulators keep tightening.

Atomic Arch belongs in the same conversation as the recent npm worm campaigns rather than as a curiosity from the Linux corner of the internet, because the playbook is the same one defenders have been losing to all year: a trusted distribution channel quietly co-opted through legitimate workflows, a build-time hook that runs before any sandbox cares, and a payload that strips a workstation of every credential it can reach. Continuous validation, kernel-aware local detection, and automated response are what stand between catching the next variant in an exercise and explaining why an engineer's laptop became the way into your cloud.