The Build Script Was The Backdoor

On AUR, Atomic Arch, and the quiet death of “just inspect the install script”

At 7:11 PM I had four tabs open and the same bad sentence forming in each of them.

The build script was the breach.

That sounds too neat, which is usually how you know the mess underneath is worse. The Arch Linux AUR story looked, at first glance, like another package malware report. A trusted-looking maintainer account. Hundreds of compromised packages. A rootkit. An infostealer. The usual grim nouns marching through the terminal in steel-toed boots.

Then the mechanics got interesting.

Attackers did not need to convince every developer to install a suspicious new package named free-money-bin. They went after the thing developers already understand badly enough to trust with confidence: community-maintained build recipes. In the Arch User Repository, the package is often less a sealed artifact than a set of instructions. A PKGBUILD. A small Bash ritual that tells your machine what to download, how to build it, and what to run along the way.

AUR has always carried the warning label. Read the PKGBUILD. Know what you are installing. Do not treat community recipes like official packages. Sensible advice. Ancient advice. Advice from a world where the script in front of you was the room.

Atomic Arch shows the room has doors.

The Poisoned Recipe

BleepingComputer reported on June 12 that more than 400 AUR packages were compromised to distribute a Linux rootkit and credential stealer. Sonatype’s research puts the first clean outline on the campaign: attackers targeted orphaned AUR packages, took over legitimate abandoned projects, then modified PKGBUILD files so installation would pull a malicious npm dependency.

That dependency was atomic-lockfile.

Then, according to Sonatype’s June 12 update, the campaign kept moving. A second wave appeared with Bun-based installation paths in some packages. Researchers connected additional packages to the activity, including js-digest and lockfile-js. Preliminary analysis suggested the blast radius may have reached roughly 1,500 packages across multiple waves.

Roughly.

That word is doing work because the count was moving while maintainers were still cleaning. The Arch mailing list turned into a triage board, with maintainers resetting or deleting malicious commits, banning accounts, and asking users to reply in-thread with more affected packages. The incident had that special open-source smell: unpaid urgency, public receipts, and everyone discovering the final number in real time.

The attack path is ugly because it is ordinary.

An AUR package changes ownership or gets adopted. The PKGBUILD changes. During installation, it invokes npm or Bun. The JavaScript package’s lifecycle hooks fire. A Linux ELF payload executes as a side effect of installing something that looked like a normal package from a familiar ecosystem.

No wizardry needed.

Just trust, chained through too many places.

The Other Package Manager Inside The Package Manager

The best part of AUR, if you are a power user, is also the dangerous part. It lets the edge of the software world arrive quickly. Proprietary apps. Nightlies. Abandoned tools. Niche drivers. Older versions that still do the one thing later releases decided to improve into uselessness.

The AUR is where Linux users go when the official repo says no and the internet says, “Here, try this.”

That bargain has always depended on a human reading the recipe. A PKGBUILD is not magic. It is text. It can be inspected. The Arch culture around it is blunt: do not install blindly.

Fine.

Now inspect this:

The recipe calls npm.

Npm reads a package.

The package has a preinstall hook.

The hook runs ./src/hooks/deps.

deps is not a helpful little helper. Whanos’ preliminary analysis describes it as a Linux credential stealer with optional root-only eBPF rootkit capabilities, aimed at developer workstations and build environments.

The script you reviewed was only the first handshake.

This is the part that makes “read the PKGBUILD” feel like checking the front door while the contractor walks through the wall with a key copied from a different building. The build recipe can be clean-looking enough to pass a tired human scan and still delegate execution to another package manager, another registry, another lifecycle system, another layer of inherited trust.

Build systems have become little border crossings. AUR to npm. Shell to JavaScript. Package recipe to lifecycle hook. Developer laptop to credential vault. Each layer asks the next one to behave.

Very brave.

The Developer Machine Was The Target

The payload details are the part where the room gets quieter.

Whanos’ analysis of the deps ELF says it targets browser and Electron app data, Slack, Microsoft Teams, Discord, GitHub, npm, Vault, Docker and Podman credentials, SSH material, VPN files, shell histories, and local developer secrets. BleepingComputer’s writeup repeats the same contour: this is built for developer workstations and build environments, not grandma’s photo folder.

That targeting matters.

A developer machine is no longer just a laptop with a text editor and bad posture. It is an identity junction. It has GitHub auth. SSH keys. Registry tokens. Cloud CLIs. Vault tokens. Docker credentials. Shell history full of commands nobody meant to keep. Browser cookies for admin panels. Chat clients. Local agents. MCP configs. Private repos. Production-adjacent access wearing a hoodie and pretending it is “dev.”

Steal that machine and you do not need to breach production in the cinematic way.

You inherit the person who can reach production.

That is why this story belongs beside the newer AI-agent security stories, even though there is no model in the middle of the AUR attack. The pressure is the same. The workstation has become the place where identity, automation, source code, package managers, cloud access, and helpful tools all sit close enough to burn together.

Once a malicious build step executes there, it can read the room better than most security teams.

It knows where developers leave keys. It knows the difference between a normal user’s cookie jar and an engineer’s Slack, GitHub, npm, and Vault material. It knows ~/.ssh. It knows .bash_history and .zsh_history. It knows Docker. It knows Podman. It knows the filesystem has memory.

So does the attacker.

The Rootkit Is Not The Main Horror

The rootkit detail is loud, so everyone hears it first.

The deps binary reportedly includes optional eBPF rootkit behavior when it has enough privilege. Whanos describes pinned BPF maps used to hide PIDs, process names, and socket inodes. BleepingComputer notes that with eBPF available, the malware can run inside the kernel with elevated privileges and hide local processes. Sonatype says the Linux executable had references to an eBPF rootkit that could hide processes, files, and network interfaces.

That is bad. Obviously.

If the malware runs as root, incident response gets uglier. Your process view lies. Your socket view lies. Live response tools may miss the thing actively draining the machine. Cleaning becomes less like uninstalling a package and more like proving your floor is still there.

But the rootkit is not the most important part.

The most important part is how boring the front door was.

A package install. A build script. A dependency fetch. A lifecycle hook. A binary tucked into a source tree. A developer machine doing exactly what a developer machine was instructed to do.

Security people spend a lot of time telling users not to run random shell commands from the internet. Then the software ecosystem built ten thousand respectable ways to run random shell commands from the internet while feeling professional about it.

curl | bash gets mocked because it looks naked.

Package installation wears pants.

Orphaned Trust

The orphaned-package angle is the part that should annoy everyone who likes clean moral lessons.

It is easy to blame users for installing from AUR. It is easy to blame maintainers for not watching every abandoned project. It is easy to blame Arch culture for being too comfortable with sharp tools. Those explanations are emotionally satisfying and mostly useless.

Open source is full of orphaned trust.

Projects go stale. Maintainers burn out. Users keep depending on the thing because it still works. Package names keep their reputation after the people behind them disappear. Adoption and ownership transfer become normal maintenance events. A new maintainer arrives, and the ecosystem has to decide whether that is rescue or compromise.

Attackers love places where trust outlives attention.

That is the pattern under Atomic Arch. The package did not have to be famous. It had to be plausible. It had to sit in a workflow where enough users and helpers would assume the name meant what it used to mean. It had to be close enough to normal that the abnormal part was already executing before anyone got bored enough to inspect it.

This is not an Arch-only problem. Arch is just honest enough to expose the bargain. Every ecosystem has abandoned packages, postinstall scripts, maintainer handoffs, dependency confusion, stale credentials, automated builds, and users who cannot personally audit the full graph because the full graph is now a metropolitan transit system made of Bash and hope.

The specific malware is Linux.

The failure mode is universal.

The Advice Got Smaller

So what do you do?

The immediate defensive advice is not mysterious. Review affected packages. Check the indicators of compromise. Treat hosts where the payload executed as credential-compromised. Rotate GitHub tokens, npm tokens, SSH keys, Vault tokens, Docker credentials, chat sessions, browser sessions, and anything else that sat within reach. Inspect user and system systemd units. Inspect /sys/fs/bpf/ for unexpected pinned maps if root execution is possible. Use trusted recovery paths if the eBPF component may have been active.

Boring. Necessary. Expensive.

The harder part is admitting that the old advice got smaller.

“Read the PKGBUILD” is still good advice. It is no longer enough advice.

You have to care what the build script calls. You have to care whether package-manager lifecycle scripts are enabled. You have to care whether npm or Bun is being invoked from inside a system package recipe. You have to care whether builds happen on a disposable machine or the same workstation that holds your GitHub session, your SSH keys, your local agent memory, and the half-finished note where you pasted a token because you were “just testing.”

You have to care about where trust crosses ecosystems.

The modern build is not a line. It is a hallway with doors on both sides.

Every door needs a policy.

The Build Room Needs A Blast Door

There is a sane future where this class of attack gets harder.

AUR helpers can make ownership changes and suspicious lifecycle behavior louder. Tooling can flag package recipes that invoke secondary package managers during install. Developers can build untrusted AUR packages inside disposable containers or VMs. Package-manager scripts can be disabled or sandboxed by default where possible. CI can separate build identity from publishing identity. Local secrets can stop living in the same room as untrusted build execution.

Most teams will do half of that after the first bad weekend.

The sharper lesson is architectural: build environments should be treated like hostile rooms. Not because every package is malicious, but because every package is an instruction bundle with access to more machinery than the original Unix gods intended after lunch.

That is doubly true now that AI coding agents and automation tools are sitting beside the same credentials. The developer workstation is becoming a control plane. It reads repos. Runs tools. Talks to APIs. Stores memory. Executes package scripts. Publishes artifacts. Opens browsers. Logs into clouds. It is where software gets made and where attackers increasingly go to become the maker.

Atomic Arch did not need the glamour of a zero-day.

It used the build.

At 8:32 PM, I closed the Whanos tab last. The source list stayed open because source lists are how I pretend to have control over the internet. Somewhere in the AUR cleanup thread, another package name had probably appeared. Another commit reset. Another account banned. Another user wondering whether their machine was merely dirty or professionally haunted.

The old warning said inspect the script before you run it.

The new warning is meaner.

Inspect the script, then inspect everything the script invites into the room.

The backdoor may be wearing the build system’s badge.