This week, attackers hijacked over 400 packages in the Arch User Repository (AUR) and modified their build scripts to deploy a credential-stealing tool on any system that compiled them.
The malicious software is a Rust-based binary designed to extract sensitive developer information. When executed with root privileges, it can also deploy an eBPF rootkit to conceal its presence. The AUR is Arch Linux’s community-driven package repository and is distinct from the official Arch repositories, which remained unaffected.
If you installed or updated an AUR package on or after June 11, verify it against the latest list of compromised packages before trusting your system. The list of affected names is extensive, still expanding, and not yet finalized.
This attack targets the trust model rather than exploiting a software vulnerability. The hijacked packages retained their original names, version histories, and the credibility associated with them—only the build instructions were altered.
The malicious code was embedded in the build recipe, making the package appear identical to the legitimate software users intended to install. There was no exploit, no zero-day vulnerability, and no indication that Arch’s own infrastructure was breached.
The attackers took over abandoned packages, modified their build files, and relied on users to execute the payload themselves. Sonatype, which identified the campaign as Atomic Arch, found that the attackers specifically targeted orphaned projects—packages whose original maintainers had stepped away, leaving them available for anyone to claim.
They also forged git commit metadata to make the changes appear as if they were made by a long-time maintainer—an account that an Arch Linux Trusted User later confirmed was never actually compromised.
Once a package was taken over, its PKGBUILD or .install script was modified to execute npm install atomic-lockfile during the build process, downloading the malicious npm package along with a few legitimate ones as camouflage. That package, atomic-lockfile@1.4.2, includes a preinstall hook that runs a bundled Linux ELF file called deps. Building the package triggers the binary.
Confirmed examples reported to the Arch mailing list include the alvr and premake-git packages.
What the malware does
Independent researcher Whanos analyzed the deps payload and identified it as a Rust-based credential stealer targeting developer workstations and build environments. It harvests:
- Cookies, authentication tokens, and local storage from Chromium-based browsers (Chrome, Edge, Brave, and others)
- Session data from Electron-based applications, including Slack, Discord, and Microsoft Teams
- GitHub, npm, and HashiCorp Vault tokens, along with OpenAI/ChatGPT bearer tokens and account metadata
- SSH keys, known_hosts files, and shell command histories
- Docker and Podman credentials and VPN configuration profiles
Stolen data is exfiltrated over HTTP to temp.sh. Command and control communication occurs through a Tor onion service via a local loopback proxy.
For persistence, it installs a systemd service configured with Restart=always. With root access, it copies itself to /var/lib/ and creates a unit file under /etc/systemd/system/; as a regular user, it uses the home directory and a per-user unit under ~/.config/systemd/user/. Either way, it’s designed to survive reboots.
Early reports exaggerated the eBPF rootkit component. It is optional and only activates when the binary already has root privileges and the necessary capabilities—it is not used to escalate privileges. When it does run, it conceals the malware’s processes, process names, and socket inodes from standard system tools using pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes, and it blocks attempts to attach a debugger.
This changes the remediation guidance. Simply removing the AUR package is insufficient once the payload has executed. A package manager can remove the files it knows about, but it cannot guarantee the system is clean after a rootkit-capable payload has had the opportunity to run.
The binary also deploys a second file associated with monero-wallet-gui, which analysts have flagged as a possible, unanalyzed cryptominer. An eBPF rootkit attached to a credential stealer is unusual, and it’s why this incident deserves more than a passing glance.
Scope and a second wave
Sonatype’s initial report identified more than 20 hijacked packages. Within a day, community trackers and the Arch aur-general mailing list thread had cataloged over 400, with one master list compiled by searching the AUR git mirror totaling approximately 408, and consolidated lists continuing to grow.
The atomic-lockfile npm package itself had only 134 weekly downloads on Socket before it was removed from the registry, so the real exposure vector is the AUR build process rather than direct npm installations.
A second wave used bun install js-digest, pushed from a separate set of accounts that community trackers link to the same npm publisher as atomic-lockfile. Its payload is a different binary—a distinct ELF file by its hash—that the community also identified as malicious.
The full extent of this second wave is still being assessed. Early breakdowns listed a few dozen packages, while later grep-based searches of the AUR mirror returned much higher numbers that may include noise as commits are removed. Regardless, it’s not a minor follow-up to the first wave, so check for both atomic-lockfile and js-digest.
What to do now
Arch maintainers are reverting the malicious commits, banning the offending accounts, and asking users to continue reporting suspicious packages in the mailing-list thread.
Treat the published list of affected packages as incomplete. On your end:
- Verify any AUR package installed or updated on or after June 11 against community-maintained package lists and detection scripts, which compare your foreign packages against the known-bad set. Search recent build history and caches for
npm install atomic-lockfile,bun install js-digest, and the payload pathsrc/hooks/deps. - If a flagged package was executed, treat the host as credential-compromised. Rotate everything the stealer targets: browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud access keys.
- Look for persistence mechanisms. Check for unknown systemd services (both system units and
~/.config/systemd/user/) and unexpected files under/var/lib/. Inspect/sys/fs/bpf/for the mapshidden_pids,hidden_names, andhidden_inodes. Review outbound connections to Tor and file-upload services. - If the package ran as root, assume the rootkit is present and reinstall the operating system from trusted media. There is no way to trust the system otherwise.
- Going forward, review the PKGBUILD and any .install hooks before building, especially for packages that were recently adopted or that suddenly became active after a long period of inactivity. If you don’t understand the build instructions, don’t install the package.
For detection purposes, the main payload’s SHA-256 hash is 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b; the full set of indicators, including the onion C2 host, is available in the ioctl.fail analysis.
The same tactic of hijacking abandoned packages was used against a PDF viewer package back in 2018; the 2026 version simply scaled it up, part of a broader pattern of supply-chain attacks that take over orphaned projects to inherit their trust rather than relying on typosquatting to deceive users. The list of affected packages remains incomplete, and no CVE has been assigned; Sonatype tracks the campaign as Sonatype-2026-003775 (CVSS 8.7).
The attack succeeded because the AUR still places more trust in a package’s name and history than in who is currently maintaining it. A recently adopted package, or one that suddenly adds new install hooks, now warrants the same suspicion as a package from an unknown source.
