Over 400 Arch Linux AUR Packages Hijacked in Developer-Focused Supply Chain Attack

Attackers did not need a Linux kernel flaw, a package manager exploit, or access to Arch Linux infrastructure to turn trusted software into a credential theft channel. They used a quieter path: adopt abandoned packages in the Arch User Repository, edit the build instructions, and wait for developers to run them.

The campaign, tracked by Sonatype as Atomic Arch, reportedly affected more than 400 AUR packages after attackers modified PKGBUILD and .install files to pull malicious npm and Bun dependencies during the build process. The official Arch Linux repositories were not reported as affected. The risk sits in the AUR trust model, where users often build community-maintained packages locally, and those build scripts execute with the privileges available in that build context.

That distinction matters. The malicious packages did not necessarily alter the upstream application users expected to install. Instead, the payload lived in the recipe used to build it. A package could keep its familiar name, old comments, and apparent history while the dangerous behavior hid in a new install hook or build step.

According to the reporting supplied, one wave added npm install atomic-lockfile, which pulled [email protected]. That npm package carried a preinstall hook that executed a bundled Linux ELF binary named deps. A second wave used bun install js-digest, with a separate ELF payload. Users should check for both patterns, not just the first npm package.

The affected platforms are developer and power-user Linux systems that built or updated compromised AUR packages on or after June 11, 2026. Arch derivatives using AUR helpers may also be exposed if they fetched and built the affected package recipes. The AUR itself is described by the Arch Wiki as user-produced package content, not the same trust boundary as official repositories. That is the practical lesson of this incident: AUR packages are code review events, not just package install events.

Independent reverse engineering attributed to researcher Whanos describes the deps payload as a Rust credential stealer aimed at developer machines. The reported collection list is broad: Chromium-family browser data, Electron application sessions, GitHub tokens, npm tokens, Vault material, OpenAI or ChatGPT bearer data, SSH keys, shell histories, Docker and Podman credentials, VPN profiles, and related local secrets. Exfiltration reportedly used temp.sh, while command and control ran through a Tor onion service via a local loopback proxy.

The persistence behavior is also significant. When run with root, the malware reportedly copied itself under /var/lib/ and wrote a systemd unit under /etc/systemd/system/. When run as a normal user, it used the home directory and a per-user systemd unit under ~/.config/systemd/user/. The service used restart behavior to survive process termination, which lines up with how systemd service units can keep a process alive if configured that way.

The eBPF element raises the severity, but it should be understood precisely. The reported eBPF rootkit behavior is not a privilege escalation path. It activates only if the malware already has enough privilege and capability to load it. Once present, it can hide process identifiers, process names, and socket inode data from normal inspection paths. Reported pinned BPF map names include hidden_pids, hidden_names, and hidden_inodes.

That makes cleanup harder. A package manager can remove files it installed knowingly. It cannot prove that a credential stealer with root-level persistence and eBPF hiding behavior left no residue. The Linux kernel eBPF documentation explains eBPF as a mechanism for running verified programs inside the kernel. In legitimate operations, it powers observability, networking, and policy enforcement. In this case, the same kernel integration reportedly helped conceal malicious activity after execution.

The attacker workflow shows why abandoned packages are valuable targets. Sonatype’s analysis, as summarized in the supplied reporting, says the attackers focused on orphaned AUR packages and spoofed git commit metadata so changes looked like they came from a long-standing maintainer. An Arch Linux Trusted User later reportedly confirmed that the apparent maintainer account had not been compromised. That detail is useful because it separates identity compromise from repository trust abuse. The package was not dangerous because a famous account was taken over. It was dangerous because maintainership had become available and users still trusted the package name.

For defenders, the first step is inventory. List AUR packages installed or updated on or after June 11, 2026, then compare them against current affected-package lists from the aur-general mailing list and community detection scripts. Treat any list as incomplete until Arch maintainers and researchers finish reconstructing the full set of modified package histories.

Next, inspect build artifacts and caches. Search for npm install atomic-lockfile, bun install js-digest, and src/hooks/deps. Also review recent AUR helper caches, local build directories, shell histories, and package build logs. The malicious behavior occurred during build or install, so the evidence may sit outside normal package ownership records.

If a flagged package was built but the payload did not execute, the host may be lower risk, though that depends on the exact build path and permissions. If the payload executed as a normal user, assume user-level secrets are exposed. Rotate browser sessions, GitHub tokens, npm tokens, Vault tokens, OpenAI API keys, SSH keys, Docker and Podman credentials, VPN profiles, and chat application sessions such as Slack, Discord, and Teams. GitHub provides guidance for managing personal access tokens, and npm documents access token management. Those rotations should happen from a clean machine.

If the package ran as root, take the incident more seriously. Look for unknown systemd services in /etc/systemd/system/ and per-user services under ~/.config/systemd/user/. Inspect /var/lib/ for unexpected binaries and review /sys/fs/bpf/ for suspicious pinned objects, including the reported map names. Check outbound traffic records for Tor activity and upload services. A rootkit-capable payload changes the response threshold: rebuilding the host from trusted media is the safer path than trying to disinfect it in place.

The operational lesson for Linux users is direct. Read the PKGBUILD and .install files before building AUR packages, especially when a package has recently changed maintainers, has been adopted after a long dormant period, or suddenly introduces new install hooks. The makepkg flow gives users the opportunity to inspect build scripts before execution. That review step is not ceremonial. In this incident, the build script was the attack surface.

For teams, AUR usage needs policy rather than habit. Developer workstations often contain the exact secrets attackers want: source access, package publishing tokens, cloud credentials, SSH keys, and internal chat sessions. If engineers are allowed to install AUR packages on production-adjacent machines, CI runners, signing hosts, or release workstations, that should be revisited. Community packaging is useful, but it should not share a trust tier with official repositories or internally reviewed packages.

A practical control is to separate build and use environments. Build AUR packages in disposable containers or virtual machines, inspect diffs before updates, and avoid building as root. Pin known-good package revisions where possible. Keep a local allowlist for packages that have been reviewed, and require a fresh review when maintainership changes or build scripts gain new network calls. Package helpers are convenient, but automation can compress the time between a malicious commit and code execution.

This incident also fits a broader software supply chain pattern: attackers are increasingly buying, adopting, or hijacking trust that already exists. Typosquatting tries to trick users into installing the wrong name. Orphan-package attacks keep the right name and change what happens behind it. That second model is harder for humans to spot because the package looks familiar until someone reads the new build instructions.

The practical takeaway is not to abandon the AUR. It is to treat it with the same skepticism given to any third-party code execution path. A package name is not a security guarantee. A long history is not proof of current maintainership. A small build-script change can matter more than a large source-code diff.

For immediate response, check recent AUR activity, search for atomic-lockfile and js-digest, rotate exposed credentials from a clean system, and reinstall any host where the payload ran with root. For prevention, review build files before running them, isolate AUR builds, and watch newly adopted packages closely. The attack succeeded because trust moved faster than review. That is fixable, but only if users and teams treat package recipes as executable code.