More than 400 AUR packages hijacked in a single coordinated campaign — that’s the headline figure coming out of the Arch Linux community this week, and it keeps climbing. Researchers at Sonatype, who named the operation Atomic Arch, began tracking it after spotting malicious build scripts quietly embedded in community packages. The payload: a Rust-compiled credential stealer capable of hoovering up developer secrets and, under the right conditions, hiding itself with an eBPF rootkit. If you run Arch and install software from the AUR, this one demands your full attention.
- Over 400 AUR packages hijacked in the ‘Atomic Arch’ campaign, installing a Rust-based credential stealer on developer machines.
- AUR packages hijacked since June 11 targeted orphaned projects, spoofing git commit metadata to look like trusted maintainer changes.
- The malware harvests browser cookies, SSH keys, GitHub tokens, and session data from Slack, Discord, and Microsoft Teams.
- A second attack wave using ‘js-digest’ via bun install is also spreading, so both vectors need checking immediately.
Table of Contents
How the AUR Packages Hijacked Attack Actually Worked
Understanding why this attack was so effective starts with understanding how the Arch User Repository works. The AUR isn’t a curated, signed software store. It’s a community-maintained collection of build scripts — called PKGBUILDs — that describe how to compile and install software from source. Users run those scripts themselves, and the trust model is largely social: you trust the maintainer, so you trust the script. That open trust model is precisely what made so many AUR packages hijacked in this campaign such a scalable attack.
The attackers understood that model better than most. Rather than trying to break into Arch’s own systems — which they didn’t — they went after the weakest point in the chain: orphaned packages. These are projects whose original maintainers had stopped caring for them, leaving them open for anyone to formally adopt. The AUR allows this by design. It’s meant to keep software available even when original authors move on. With hundreds of AUR packages hijacked through this single gap, the damage potential was enormous before a single warning was issued.
Once an abandoned package was adopted, its PKGBUILD or .install script was quietly edited to run npm install atomic-lockfile during the build process. That pulled in a malicious npm package — atomic-lockfile@1.4.2 — alongside a couple of legitimate packages for cover. The malicious package carried a preinstall hook that executed a bundled Linux ELF binary named deps. Build the package, and you run the payload. No prompt, no warning, no indication anything unusual happened.
To make the changes look legitimate, the attackers spoofed git commit metadata so the modifications appeared to come from a long-standing maintainer. An Arch Linux Trusted User later confirmed that account was never actually compromised — the appearance of authenticity was manufactured. Confirmed affected packages reported to the Arch mailing list include alvr and premake-git, though the full list of AUR packages hijacked in this campaign is still being compiled.
What the Malware Actually Does to Your Machine
Independent researcher Whanos reverse-engineered the deps binary and published findings that paint a thorough picture of what it’s after. This isn’t opportunistic adware. It’s a focused credential harvester built specifically for developer workstations — the kind of machines that tend to hold the keys to far larger infrastructure. Every system on which AUR packages hijacked by this campaign ran a build script is a machine that needs to be treated as compromised.
The stealer collects cookies, tokens, and local storage from Chromium-based browsers including Chrome, Edge, and Brave. It targets session data from Electron apps — Slack, Discord, Microsoft Teams — which means it can walk away with live authenticated sessions that don’t require a password to reuse. It goes after GitHub and npm tokens, HashiCorp Vault access material, OpenAI and ChatGPT bearer tokens, SSH keys and known_hosts files, shell histories, Docker and Podman credentials, and VPN profiles.
Everything exfiltrated goes out over HTTP to temp.sh. Command and control runs through a Tor onion service via a local loopback proxy, keeping the attacker’s infrastructure opaque. For persistence, the malware installs a systemd service configured with Restart=always. With root, it copies itself into /var/lib/ and writes a unit file to /etc/systemd/system/. Without root, it uses the home directory and a per-user unit at ~/.config/systemd/user/. Either way, it comes back after a reboot.
The eBPF rootkit component received a lot of early attention, but the analysis suggests it was somewhat overhyped in initial reports. It’s optional and only activates when the binary already has root and the required capability — it isn’t used to escalate privileges. When it does run, it hides the malware’s own processes, process names, and socket inodes from standard tools using pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes. It also kills attempts to attach a debugger. That’s not a footnote — it’s a meaningful anti-forensics capability. There’s also a second staged file tied to monero-wallet-gui that analysis flags as a possible cryptominer, though it hasn’t been fully analyzed yet.
The Scale: 400 AUR Packages Hijacked and a Second Wave
Sonatype’s initial write-up counted more than 20 compromised packages. Within roughly 24 hours, the community had cataloged over 400 AUR packages hijacked across the campaign. One master list compiled by grepping the AUR git mirror put the count at approximately 408, with consolidated community lists running higher. The npm package atomic-lockfile itself showed only 134 weekly downloads on Socket before it was pulled from the registry — a reminder that the real exposure here was the AUR build path, not direct npm installs. Most victims never touched the npm package directly; their AUR build script did it for them.
Then came a second wave. This one uses bun install js-digest instead of npm, pushed from a separate set of accounts that community trackers link to the same npm publisher behind atomic-lockfile. Its payload is a different binary — a distinct ELF by hash — that the community has also flagged as malicious. Seeing a fresh batch of AUR packages hijacked through this second vector so quickly after the first confirms this wasn’t a one-off experiment. How far this second wave has spread is still being counted. Early tallies listed a few dozen packages, while grep-based searches of the AUR mirror returned considerably higher numbers that may include some churn as commits are removed and lists are refined. Either way, it’s not a minor variant. Both atomic-lockfile and js-digest need to be on your radar.
Why AUR Packages Hijacked at This Scale Is a Warning for Open-Source Trust Models
What makes the AUR packages hijacked campaign particularly instructive — beyond the technical sophistication of the payload — is what it reveals about trust in open-source ecosystems. There was no exploit here. No zero-day, no breach of Arch’s own infrastructure, no vulnerability in any piece of software. The attackers simply walked through a door the community had left unlocked: the ability to adopt unmaintained packages and modify their build instructions.
This isn’t unique to Arch. The npm ecosystem has had its own waves of dependency hijacking and typosquatting. PyPI has dealt with malicious packages mimicking popular libraries. The RubyGems registry has seen similar campaigns. What’s different here is the scale — over 400 AUR packages hijacked in a single coordinated operation — and the targeting. Developer workstations are enormously valuable targets. A stolen GitHub token or an SSH key can unlock production infrastructure. A harvested Vault token can mean access to secrets across an entire organization’s cloud environment. The attackers weren’t going after end users. They were going after the people who build software.
The eBPF rootkit component is also worth sitting with. Bolting a kernel-level hiding mechanism onto a credential stealer is a meaningful escalation in sophistication for an AUR campaign. It shifts the cleanup calculus entirely — you can’t simply uninstall a package and call the machine clean. If the payload ran, and especially if it ran with root, the only truly safe remediation is treating the host as fully compromised. When AUR packages hijacked by this technique have been building on your system, uninstalling them is not enough.
What You Need to Do Right Now
Arch maintainers are resetting the malicious commits, banning the accounts involved, and asking users to report suspect packages in the aur-general mailing list thread. Treat any published affected-package list as incomplete — the count of AUR packages hijacked is still moving.
- Check any AUR package installed or updated on or after June 11 against community detection scripts that compare your installed foreign packages against the known-bad set.
- Grep your recent build history and cached PKGBUILDs for npm install atomic-lockfile, bun install js-digest, and the path src/hooks/deps.
- If a flagged package ran on your system, treat the host as credential-compromised. Rotate everything: browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams, and Discord sessions, HashiCorp Vault tokens, Docker and Podman credentials, and any cloud access keys.
- Hunt for persistence. Check for unknown systemd services in both system units and ~/.config/systemd/user/. Look for unexpected files under /var/lib/. Inspect /sys/fs/bpf/ for the maps hidden_pids, hidden_names, and hidden_inodes.
The broader lesson here isn’t that the AUR is uniquely dangerous — it’s that any package ecosystem with an open adoption model for unmaintained projects carries this kind of risk. The AUR has always been explicit that its packages come with less vetting than official repositories. What’s changed is that attackers are now willing to put serious capability behind exploiting that gap, as the sheer number of AUR packages hijacked in this single operation makes clear. Expect the community to push for stronger safeguards around orphaned package adoption. Whether the AUR’s decentralized ethos can accommodate those safeguards without losing what makes it useful is the harder question — and one the Arch community is now being forced to answer under pressure.
Source: The Hacker News
Frequently Asked Questions
How do I check if any AUR packages hijacked in this campaign affected my system?
Check any AUR package installed or updated on or after June 11 against community detection scripts. Grep your build history and caches for ‘npm install atomic-lockfile’, ‘bun install js-digest’, and the payload path src/hooks/deps. Community-compiled lists and the Arch aur-general mailing list thread are the most current reference.
What credentials does the Atomic Arch malware steal?
The Rust payload collects cookies and tokens from Chromium-based browsers, session data from Electron apps like Slack and Discord, GitHub and npm tokens, OpenAI bearer tokens, SSH keys, shell histories, Docker and Podman credentials, and VPN profiles. All exfiltrated data is sent over HTTP to temp.sh.
Is removing the affected AUR package enough to clean an infected system?
No. Once the payload has executed, removing the package through a package manager isn’t sufficient. The malware installs a persistent systemd service and, with root access, can load an eBPF rootkit that hides its own processes. The safest assumption is that the host is compromised and credentials should be fully rotated.
Were Arch Linux’s official repositories affected by this attack?
No. The attack was confined to the AUR, which is a community-maintained package collection separate from Arch’s official repositories. Arch’s own infrastructure was not breached. The attackers exploited the AUR’s open adoption model for unmaintained packages rather than any flaw in Arch Linux itself.
