It's a trust model attack, not a Linux flaw: hackers adopted orphaned packages in the Arch User Repository (AUR), Arch's community run package collection separate from the official repos, and rewrote their build scripts so users installed the malware themselves.
The "premake-git" package on Arch Linux's community-run package hub had a normal history, a recognizable maintainer trail, and no obvious warning signs. On June 11, that changed. Anyone who ran the standard build or update command on premake-git from that point forward installed credential-stealing malware on their own machine. The same pattern, as reported by The Hacker News, now reaches more than 400 packages in the Arch User Repository (AUR), Arch's community package collection, separate from the official Arch repositories that were not affected.
This is a trust-model attack, not a Linux vulnerability. Attackers adopted orphaned AUR packages, projects whose original maintainer had stepped away and that any registered user can take over, then rewrote the build recipe (the PKGBUILD) and post-install hook. The user, not the attacker, ran the command that dropped the payload. There is no software flaw to patch, no zero-day, and no breach of Arch's own systems. The attack surface is the trust model.
The payload is a Rust binary that, when it lands on a host running as root, can load an eBPF rootkit — a Linux kernel feature being repurposed, once the malware lands with root, to hide its own files and processes. According to independent researcher Whanos, the binary harvests: browser cookies, tokens, and local storage from Chromium-based browsers including Chrome, Edge, Brave, and others; session data from Electron apps including Slack, Discord, Microsoft Teams, and Telegram; GitHub, npm, and HashiCorp Vault tokens; OpenAI/ChatGPT bearer material; SSH keys, known_hosts, and shell histories; Docker and Podman credentials; and VPN profiles. Sonatype, which is calling the campaign "Atomic Arch" (tracking it as Sonatype-2026-003775, CVSS 8.7), estimates the campaign may now affect approximately 1,500 packages across multiple waves of activity — a figure that has grown rapidly from initial counts of more than 20. A second wave, emerging on June 12, used bun install js-digest in place of the npm path, pushing from a separate set of accounts the community links to the same npm publisher as atomic-lockfile, with a different payload binary.
The delivery mechanism: the PKGBUILD or .install script was edited to run npm install atomic-lockfile during the build, pulling the malicious npm package alongside a couple of legitimate ones for cover. The package, atomic-lockfile@1.4.2, carries a preinstall hook — a script that runs automatically when a package is installed, before the package itself is unpacked — that executes a bundled Linux ELF named deps. Build the package, and the binary runs. The malicious npm package showed only 134 weekly downloads on the registry before it was pulled; the real exposure is the AUR build path, not direct npm installs. Confirmed examples reported to the Arch mailing list include the alvr and premake-git packages.
The mechanism generalizes. Any community-run package ecosystem that lets volunteers adopt orphaned projects and run arbitrary build scripts is exposed to the same attack. npm, PyPI, and Homebrew taps all carry variants of the pattern. The AUR is the visible instance today, not the only possible target. Naming 400 or 1,500 affected packages is a scale beat; the structural point is that the trust signals a user can see in the AUR's web interface — maintainer history, last-edited timestamps, orphan status — are exactly the signals the attackers learned to forge or exploit. "Always read the PKGBUILD" is not a security posture; it is the advice the attackers designed around.
The list of confirmed hijacked package names is still growing and not yet complete, per The Hacker News, and an official Arch-side disclosure with primary-source indicators, hashes, and an authoritative affected-package list had not been published at the time of this report. Concrete indicators of compromise from the independent researcher analysis include the main payload's SHA-256: 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b. Exfiltration goes to temp.sh over HTTP; command and control routes through a Tor onion service (olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion) via a local loopback proxy. The eBPF rootkit, when activated, uses pinned BPF maps named hidden_pids, hidden_names, and hidden_inodes to hide process and socket artifacts. Concrete mitigations live in tooling rather than in user vigilance: signed builds, maintainer-vacancy signals that escalate before a package is fully orphaned, package-rebuild diffs that flag new network calls, and review of pre-install hooks for transitive dependencies. The community-run package model is not going away. The question is whether the next such incident is detected in hours, after a single AUR user's first build, or in days.