The Package You Installed Last Night Just Became a Rootkit
Here's the thing about open-source repositories that nobody wants to hear: trust is a feature, not a guarantee. The Arch User Repository — AUR for short — has always operated on that principle. It's a community-maintained catalog of build scripts, and if you're running Arch or any derivative like EndeavourOS or Garuda, you've probably pulled something from it. Maybe this morning. Maybe last night while half-asleep.
As of mid-June 2026, more than 400 packages in that repository are actively distributing a Linux rootkit and an infostealer designed to rip credentials, access tokens, and developer secrets straight off your workstation. Two separate threat campaigns converged on the same target using different techniques, and both landed on the same payload: a malicious npm package called atomic-lockfile that drops an ELF binary with eBPF rootkit capabilities and a comprehensive credential-stealing module.
This isn't a theoretical risk. If you've installed anything from AUR in the last few weeks, your machine might already be compromised. And the implications reach far beyond Arch Linux.
How Two Campaigns Hijacked the Same Repository
The first campaign, documented by IFIN member Michael Taggart, works through account spoofing. A threat actor impersonated a trusted publisher on the AUR platform and pushed infected packages under that identity. The compromised PKGBUILD scripts contain preinstall hooks that download and execute the malicious atomic-lockfile npm package the moment a user runs yay -S or paru -S against one of these packages.
The second campaign, independently reported by Sonatype's researchers, took a different route. Instead of spoofing an existing maintainer, the attacker hijacked at least 20 orphaned packages — those neglected projects where the original maintainer walked away and anyone can adopt the build script. The modified PKGBUILD files add a post-install script that invokes npm and pulls in atomic-lockfile during the package installation process.
Both methods exploit the same fundamental weakness: AUR has no signing requirement, no mandatory code review before publication, and no mechanism to prevent a malicious actor from adopting an abandoned package. The community runs on honor, and honor doesn't stop a determined attacker.
What the Malware Actually Does Once It Lands
Independent security researcher Whanos analyzed a sample of the resulting ELF payload and found something that should make every developer's blood run cold. The binary is a credential stealer with optional root-only eBPF rootkit capabilities, and it's specifically designed for developer workstations and build environments.
The infostealer module targets an exhaustive list of sensitive data sources: browser and Electron application cookies, Slack sessions, Microsoft Teams tokens, Discord credentials, GitHub personal access tokens, npm authentication data, HashiCorp Vault secrets, Docker and Podman configurations, SSH keys, VPN credentials, shell history files, and just about any other local developer secret you'd store on a machine you use for work.
The eBPF rootkit component is what elevates this from a nasty infostealer to something genuinely dangerous. By running inside the kernel with elevated privileges, the malware can hide local processes, files, and network interfaces from standard system monitoring tools. Your antivirus sees nothing. Your process list shows nothing. The malware is there, and you won't know it's there.
Sonatype confirmed the binary can archive stolen data, handle multi-part file uploads, and perform HTTP exfiltration — meaning this isn't just a local collector. It phones home.
The Orphaned Package Problem Nobody's Fixing
The orphaned package vector is particularly insidious because it turns a feature of AUR into a vulnerability. When a maintainer abandons a package, the community adopts it — sometimes within hours. There's no background check. No verification that the new maintainer actually understands what they're installing. No requirement to audit the build script before publishing.
Jonathan Grotelüschen, an Arch Linux package maintainer, addressed the community directly and urged users to report any malicious packages they encounter. But reporting after the fact doesn't help the people who already installed those packages.
The orphaned package problem extends well beyond AUR. Every major open-source repository — PyPI, npm, crates.io, the RubyGems registry — faces this same vulnerability. A package goes dormant. Someone adopts it. And suddenly that dormant package becomes a delivery mechanism for malware.
This is why the npm v12 decision to require explicit approval for install scripts and non-registry dependencies matters so much. It's a step in the right direction, even if it doesn't solve the underlying trust problem.
What This Campaign Reveals About Artificial Intelligence Cybersecurity Threats
There's a natural tendency to treat supply chain attacks as isolated incidents — someone compromised a repo, we patched it, move on. But the AUR rootkit campaign reveals something more disturbing about the evolving landscape of artificial intelligence cybersecurity threats.
The malware's design philosophy — comprehensive credential harvesting across every possible developer tool, eBPF-level stealth capabilities, automated exfiltration — suggests a level of sophistication that goes beyond opportunistic crime. This is infrastructure-grade malware being deployed against open-source repositories at scale.
And here's where it gets uncomfortable: as AI coding agents become more prevalent in developer workflows, the attack surface expands dramatically. An AI agent that automatically installs packages from a repository on behalf of a developer is essentially automating the trust decision. If that agent pulls a compromised package, the credential theft happens before any human ever looks at their terminal.
The Miasma worm campaign that targeted AI coding agents earlier this year was a preview of exactly this threat model. The AUR attack is the same playbook, applied to a different repository ecosystem. The pattern is clear: threat actors are systematically targeting the packages that AI agents and automated build pipelines consume.
How to Check If You're Compromised
Michael Taggart published a detection script that checks for the presence of atomic-lockfile on your system. If you've installed anything from AUR recently, run that script now.
The indicators of compromise documented by Whanos include the presence of the deps ELF binary, suspicious npm packages in your local cache, and unexpected eBPF programs loaded into the kernel. You can check for eBPF rootkit activity using tools like bpftrace or by examining loaded kernel modules for anything unusual.
If you find evidence of compromise, the advice is blunt: rotate every credential you've ever used on that machine. GitHub tokens, SSH keys, Vault secrets, browser sessions — everything. And then consider reinstalling Arch from scratch. A rootkit with eBPF capabilities may survive a normal cleanup effort, and you don't want to leave that kind of access sitting in your kernel.
What Needs to Change Before the Next Wave Hits
The AUR community is working to identify and remove all malicious commits and ban the accounts pushing them. That's necessary, but it's not sufficient.
We need mandatory package signing for repositories that serve as primary installation sources. We need reproducible builds so users can verify that what they're installing matches the source code. We need time-delayed publication windows where new packages sit in a staging area before becoming available to the general public — giving security researchers and automated scanning tools time to flag malicious content.
And we need to stop treating open-source repositories as inherently trustworthy. They're community projects maintained by volunteers, and that's one of their greatest strengths. But it also means they're the weakest link in the software supply chain.
The next campaign won't wait for us to fix these problems. It's already being written somewhere, targeting the next orphaned package, waiting for someone to run yay -S.
