Over 400 Arch Linux AUR Packages Hijacked to Spread eBPF Rootkit and Credential Stealer

More than 400 packages in the Arch User Repository (AUR) were caught distributing a Linux rootkit and an infostealer built to harvest credentials and access tokens. The campaign targets exactly the kind of machine that tends to hold the keys to everything else: a developer's workstation, loaded with SSH keys, cloud tokens, and signed-in chat apps.

The activity was flagged by the Independent Federated Intelligence Network (IFIN), an open-source intelligence community, which observed a new maintainer spoofing a trusted publisher to slip infected packages into the AUR. That detail matters because the AUR runs on trust rather than vetting.

Why the AUR is such an attractive target

The Arch User Repository is a community-maintained catalog of build scripts, called PKGBUILDs, that tell your system how to download, compile, and install software that isn't in Arch's official repositories. Proprietary apps, nightly builds, niche utilities, and older package versions all live there. For most Arch Linux users, the AUR isn't optional. It's how you actually get the software you want.

That convenience comes with a structural weakness. The AUR is not a vetted space. Packages can change ownership quietly, and a PKGBUILD is just a Bash script that runs build commands on your machine. Nobody is standing between a malicious commit and your terminal except you, reading the script before you build it. Plenty of people don't.

How the attack works

According to IFIN member Michael Taggart, the compromised packages were modified with preinstall scripts that pull down and execute a malicious npm package called atomic-lockfile. Independent researcher Whanos examined a sample and found it shipped a Linux ELF payload named deps, described as a "credential stealer with optional root-only eBPF rootkit capabilities."

The targeting is deliberate. Whanos notes the malware is "designed for developer workstations and build environments," going after browser and Electron application data, Slack, Microsoft Teams, Discord, GitHub, npm, Vault, Docker and Podman, SSH, VPN material, shell histories, and other local developer secrets.

The eBPF component is the part worth understanding. Extended Berkeley Packet Filter started life as a way to run small programs inside the Linux kernel for networking and observability, and it has become a foundation for tools like tracing, security monitoring, and performance analysis. When a payload gains root and loads its own eBPF program, it gets the same kernel-level vantage point those legitimate tools use, which means it can hide processes, files, and network interfaces from the rest of the system. A rootkit operating at that layer is far harder to spot than malware sitting in userspace, because the tools you'd use to find it are asking the kernel questions the kernel has been told to answer dishonestly.

Two reports, two delivery methods

Supply-chain firm Sonatype published a parallel report on the same atomic-lockfile package, but described a different intrusion path. Sonatype's researchers say the attacker hijacked at least 20 orphaned AUR packages, ones whose original maintainers had abandoned them, and modified the PKGBUILD to add a post-install hook that invokes npm and fetches the malicious package during installation.

"The modified packages add a post-install script that invokes npm and installs atomic-lockfile during package installation," Sonatype says. Their analysis found the same Linux executable with references to an eBPF rootkit capable of hiding processes, files, and network interfaces. The binary's infostealer side reaches for GitHub credentials, SSH artifacts, HashiCorp Vault tokens, browser cookie databases, and data from Slack, Discord, Microsoft Teams, and Telegram. Sonatype also determined the binary can archive data, handle multi-part files, and perform HTTP uploads, which covers everything an attacker needs to stage and exfiltrate what it collects.

The two delivery techniques, publisher spoofing in one case and orphaned-package hijacking in the other, point to a campaign probing several weak spots in the same ecosystem rather than relying on a single trick.

What to do if you run Arch

AUR maintainers are working to identify and remove the malicious commits and ban the accounts behind them. Arch package maintainer Jonathan Grotelüschen asked the community to report any malicious package they come across.

For users, the practical steps are concrete. Review the list of affected packages and check your system against the indicators of compromise in Whanos's report. Taggart also pointed to a script that checks specifically for the atomic-lockfile malware. If you find evidence of compromise, rotate every credential the malware could have touched, GitHub tokens, SSH keys, Vault tokens, VPN material, and chat sessions included, and assume reinstalling Arch from scratch is the safest path. A kernel-level rootkit can survive ordinary cleanup, so half-measures leave you guessing.

The broader habit worth building is treating the AUR like the unvetted source it is. Read PKGBUILDs before you build, be wary of packages that recently changed hands or sat orphaned, and lean toward projects with frequent updates and an active community. None of that is foolproof, but it raises the cost for an attacker counting on nobody looking. This campaign fits a wider run of supply-chain attacks against package ecosystems, from npm and PyPI to the self-spreading Shai-Hulud worm, and the common thread is the same: the install step is now part of your attack surface, and the people maintaining your dependencies are part of your threat model whether you've thought about them or not.