Hackers Hijacked 400 Arch Linux AUR Packages to Install Malware

More than 400 packages in the Arch User Repository (AUR) were hijacked this week, and the attacker never broke into a single system to do it. They took over packages whose makers had walked away, then let people install the malware during a routine update they had no reason to question. 🐧

The AUR is the place where community members write and share the recipes for installing software that is not in the official Arch repositories. Publishing there is open to the community, and Arch based systems pull straight from it. That openness is one of the reasons people love Arch, and it is also why this played out the way it did. The official Arch repositories were never touched.

When the person maintaining one of those community packages walks away, the package becomes an orphan. After that, another user can ask to adopt it and take over the recipe. The process is normal, and most of the time it keeps useful software alive when the original author loses interest. This time someone used it to inherit packages that already carried years of trust, without having to earn any of it.

Each AUR package ships with a build recipe called a PKGBUILD, a script that tells your machine how to fetch and build the software. Some packages also include a small .install or .hook file that runs commands during installation. When you install something from the AUR, a helper like yay or paru reads that recipe and runs it for you, usually without you reading a line of it. The AUR is not reviewed or vetted by Arch, and that is the deal you accept when you use it, so the recipe runs on trust. The attacker left the actual software alone and rewrote the recipe.

The rewritten recipe pulled in an npm package while the package was being built. Across the hijacked packages the line looked a little different each time, padded with a few real npm packages so it would blend in with a normal dependency list:

1
2
3

npm install atomic-lockfile yargs
npm install atomic-lockfile dotenv axios
npm install atomic-lockfile chalk minimist

The one that mattered was atomic-lockfile. The others were there to make the line look ordinary.

atomic-lockfile carried a single instruction in its own package.json that runs a bundled program the moment the package installs:

1

"preinstall": "./src/hooks/deps"

deps has one job. It grabs the logins and secrets it can find on your machine. A credential stealer, written in Rust. Build a hijacked package and it runs before you ever open the software you wanted.

Once it starts, deps goes hunting for the things a developer keeps lying around. Browser cookies and saved sessions from Chromium based browsers. SSH keys and known_hosts. GitHub and npm tokens. HashiCorp Vault tokens. Docker and Podman logins. VPN profiles. Shell history. Session data from Slack, Microsoft Teams and Discord.

Then it ships everything out. The stolen files go to a public upload site called temp.sh. For its orders it phones a server hidden on the Tor network, reached quietly through a connection on your own machine at 127.0.0.1. That hidden server is its command and control. It can also pull one more file from there, maybe a cryptominer, though that part is unconfirmed.

It also wants to survive a reboot. So it sets itself to start again every time the machine boots, using a systemd service, the normal way Linux runs things in the background. With root it hides that under /var/lib. Without root it tucks it into the user’s own config folder. Either way, it comes back.

With root and one extra kernel permission, it pulls a nastier trick. It makes itself disappear. The tool for that is an eBPF rootkit, a small program that runs inside the kernel, the core of Linux. deps uses it as a cloak. When any tool asks the system for the list of files in a folder, that request runs through one kernel call named getdents64. The malware sits on top of it and strips out its own files and processes before the answer comes back, so the tool sees a folder that looks clean and is not. Try to attach a debugger to study it, and it shuts that down too.

Several early reports made this rootkit sound like the main event. It is not. It only switches on when the malware already has root, and it is not how it got root in the first place. It is a cloak, not a key.

The stolen credentials are where this spreads beyond one machine. A stolen npm token can publish a backdoored version of a package under the victim’s own name. A stolen GitHub token can push code straight into repositories the victim controls. A developer who builds one poisoned package does not only lose their own secrets, they can become the delivery route for the next attack against the people who trust their work. That is how a single compromised laptop turns into a chain.

The git history is the part to read slowly. The attacker did not sign the work with some obvious throwaway name. In the commits they kept the real names of the original maintainers and changed only the email behind them. One of those names, a maintainer called arojas, had nothing to do with it. They faked that identity in the commit data, and an Arch developer had to say so out loud the next day once people started pointing fingers.

That is how slippery attribution gets. The names, the email addresses, the tools left behind in the code can be faked. What holds up is how the malware works, not who appears to have signed for it.

A day later a second wave started. Same idea, different tools. This time it skipped npm and used bun, another way to install JavaScript packages, pulling one called js-digest with its own hidden binary. Same npm account behind it as the first round. The switch was not random. A detection rule looking for that first npm install line would not flag a bun command at all.

The trick itself, a hidden binary set off by an install hook, matches another npm campaign from a week earlier called IronWorm. It is also Rust, also carries an eBPF rootkit, and the overlap runs deeper than the building blocks. IronWorm calls home to a Tor hidden service on the same path, /api/agent, and offloads stolen files to the same public host, temp.sh. deps does both. Researchers have not confirmed it is the same people, and until they do, that is where the honest answer sits.

The number keeps moving while the cleanup goes on. Sonatype, the company that gave the campaign its name, Atomic Arch, first counted around twenty hijacked packages. A day later, people searching through a copy of the AUR were finding four hundred and counting, and one estimate put the total across both waves near fifteen hundred. The lists are not complete and they are still growing, so treat any number as where things stood that moment, not a final score.

There is no CVE number for this one. Nothing was technically broken, so it does not fit the box a CVE goes in. Sonatype tracks it under its own reference, Sonatype-2026-003775, and rates it high at 8.7.

This is not the first time the AUR’s open adoption has been turned against it. In 2018, someone using the name xeactor adopted an abandoned PDF viewer package called acroread, along with two others, and slipped in a script that set a systemd timer to phone home every six minutes and collect details about the machine. It was small and clumsy next to this one, and it was caught quickly. The tactic is the same, eight years apart. What changed is the scale and the payload, from a data collecting timer then to a Rust credential stealer with a kernel rootkit now.

If you build from the AUR, this is where to look and what to do. Start with anything installed or updated since June 9. Your AUR helper keeps the build files in its cache, so you can search them directly:

1
2

grep -r "npm install atomic-lockfile" ~/.cache/yay ~/.cache/paru
grep -r "bun install js-digest" ~/.cache/yay ~/.cache/paru

The indicators to match against:

• → Malicious npm package: atomic-lockfile @ 1.4.2, pulled in by an edited PKGBUILD or .install file
• → Second wave package: js-digest, installed through bun, with lockfile-js also tied to the campaign
• → Payload inside the package: src/hooks/deps
• → deps SHA-256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b
• → Second wave ELF SHA-256: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316
• → Persistence: a systemd service set to Restart=always, under /var/lib or ~/.config/systemd/user
• → eBPF rootkit maps: /sys/fs/bpf/hidden_pids, /sys/fs/bpf/hidden_names, /sys/fs/bpf/hidden_inodes
• → Exfiltration: stolen files uploaded to the file sharing service temp.sh
• → Command and control: the onion host olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion, reached over Tor through a local 127.0.0.1 proxy
• → npm account behind both packages: herbsobering

The response, in order:

• → Read the PKGBUILD and any .install or .hook file before you build, and walk away from anything that runs npm, bun or pip for software that has no reason to touch them
• → If a flagged package ran, treat the machine as credential compromised and rotate the credentials the stealer reaches: browser sessions, SSH keys, GitHub and npm tokens, Vault tokens, Docker and Podman logins, Slack, Teams and Discord sessions, and any cloud keys
• → Check for unknown systemd services, and inspect /sys/fs/bpf for those hidden_ maps from a system you trust rather than the suspect one
• → Review outbound connections and any Tor or proxy logs for traffic to the onion host listed above
• → If the payload ran as root, reinstall from trusted media, because once a kernel level rootkit has had its moment there is no clean way to prove the machine is honest again

This malware steals credentials, sets up persistence so it survives a reboot, hides itself from the usual tools, and is built to keep moving once it has a foothold. Post exploitation, privilege escalation, persistence, credential theft and moving through a network without being seen are what my ethical hacking course walks through step by step:

• → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources: Sonatype | ioctl.fail | Arch Linux aur-general