Arch Linux Freezes AUR Adoption: Tor

The attackers behind the Atomic Arch supply chain campaign have adapted. After Arch Linux developers purged more than 1,900 compromised packages and declared the community repository clean in mid-June, the threat returned with a delivery mechanism specifically engineered to evade the detection signatures that caught the earlier waves — and this time the project's response was not a cleanup, but a lockdown .

Robin Candau, a contributor acting on behalf of the Arch Linux DevOps team, posted an emergency notice to the project's official mailing list on July 30, 2026. "Due to the current influx of malicious package adoptions and follow-up commits made via the AUR, package adoption is currently disabled while we are handling the situation," Candau wrote. "We will send a follow-up once we're able to. In the meantime, feel free to report suspicious adoption events or commits that haven't been dealt with yet, and stay vigilant!" No timeline for restoring the adoption mechanism has been given.

A user tracking the campaign estimates it has reached more than 200 AUR packages, per a community tracking thread . Arch Linux has not confirmed that figure or published a complete list as of publication.

The Arch User Repository holds over 90,000 community-contributed software packages — tools, drivers, and applications that don't appear in Arch's vetted official repositories. When a package maintainer abandons a project, the AUR marks it "orphaned." Any registered user can then adopt the orphaned package, become its new maintainer, and push updated build instructions.

That mechanism is also the entry point the Atomic Arch campaign has exploited across all three of its waves. Attackers file legitimate adoption requests for orphaned packages, inherit their names and trusted histories, and rewrite their build scripts to execute malicious payloads during installation. No intrusion is required — just a free account and a list of abandoned packages with established user bases, as documented in the orphaned package adoption exploit .

The adoption freeze doesn't shut down the AUR. Existing maintainers can still push updates to packages they already own. But it does cut off the primary entry point attackers have used throughout this campaign.

In June, the Atomic Arch campaign's delivery vector was detectable: attackers modified PKGBUILD scripts — the shell scripts that Arch's makepkg tool executes during installation — to run npm install atomic-lockfile , a command that pulled a malicious JavaScript dependency from the public npm registry, as detailed in Sonatype's Atomic Arch analysis . That pattern was visible to text-based scanning: look for npm install atomic-lockfile in a PKGBUILD, and you've found a compromised package.

Wave Three, which began July 29 with the package openconnect-sso , uses a different architecture — one that the npm-pattern scanners Arch deployed after June's cleanup cannot catch, according to IFIN's technical analysis . The new wave embeds compiled ELF binaries directly into build scripts or uses obfuscated shell downloaders that execute during the makepkg build phase. There is no npm install to for.

Once the first-stage loader runs, it performs anti-analysis checks — looking for debuggers, sandboxes, virtual machines, and CI/CD environments — before taking any further action, as confirmed by stage-one loader analysis . This means automated analysis pipelines that build packages in sandboxed environments may see clean behavior while the malware activates on real developer workstations. If no analysis environment is detected, the loader installs systemd services and cron jobs for persistence, then deploys a Tor client binary disguised as dbus-daemon — a legitimate Linux inter-process communication daemon — and connects through it to a command-and-control server hosted on a Tor .onion address. Routing the C2 channel through Tor makes the server's location and operator nearly impossible to identify through network analysis, and makes the connection nearly impossible to block through conventional IP-based firewall rules.

The second-stage payload retrieved from the Tor C2 server is a compiled Rust binary targeting x86_64 Linux systems, per stage-two payload analysis . Rust was almost certainly chosen for its combination of low-level performance and resistance to reverse engineering — compiled Rust binaries are significantly harder to decompile into readable code than Python, JavaScript, or Go equivalents, slowing analysis.

The credential harvesting scope is comprehensive. The stealer targets stored passwords and session tokens in Chromium-family and Firefox-family browsers, cryptocurrency wallet files and seed phrases, password manager databases, cloud provider API keys (AWS, Azure, GCP), AI service API keys (OpenAI, Anthropic, and others), CI/CD pipeline secrets and GitHub tokens, and SSH private keys stored in ~/.ssh/ .

That last target category carries consequences that extend well beyond the individual whose machine was compromised. The second-stage payload includes an SSH worm component: using the stolen private keys, it identifies systems listed in the victim's known_hosts and authorized_keys files, copies itself to those machines over SSH, and executes, as IFIN's analysis confirmed . An Arch Linux developer who uses SSH keys to access production servers, build infrastructure, cloud instances, or colleagues' machines has — without any further action by the attacker — handed over lateral movement capability across their entire SSH trust graph.

For organizations with even one Arch workstation in their developer environment, this is not a per-user credential theft incident. It is a potential enterprise infrastructure breach in which the attacker's foothold may already extend beyond the original victim machine, silently, using authentication credentials that production systems trust.

Additionally, the malware provides the attacker with remote command execution over the encrypted Tor channel — meaning affected systems may be under active remote control independent of the exfiltrated credentials.

The July 30 lockdown is the third major response Arch Linux has mounted to this campaign. The first wave, detected June 11, 2026, compromised more than 400 packages using the npm-based delivery method — a figure that Sonatype researchers and the Arch Linux mailing list tracking thread later revised upward to approximately 1,500 . Arch developers ultimately purged more than 1,900 compromised packages and suspended new account registrations before declaring the repository clean in mid-June, per Arch Linux's third-wave response .

The second and third waves resumed despite that cleanup, with the third wave deploying the Rust/ELF payload architecture described above — a direct adversarial response to the detection methods Arch published after June's incident.

Specific packages named in Wave Three community tracking include openconnect-sso , boringssl-git , icloudpd , windscribe-cli-v2-bin , stirling-pdf-desktop-bin , arduino-language-server-noclang-bin , pgadmin4-server , i915-sriov-dkms , rtk-git , warp-terminal-git , weather-display , and astro-box , per the Phoronix named-packages list and the tracking list . That list is almost certainly incomplete.

The official Arch Linux repositories — [core] , [extra] , and [multilib] — are maintained by vetted developers and are not affected in any wave of this campaign. Users running only official repository packages face no direct exposure from the Atomic Arch campaign.

The AUR exists separately from the official repositories and has always carried an explicit community warning that packages are not vetted and users install them at their own risk. That caveat has not changed — but the practical reality, as this campaign demonstrates, is that the "inspect PKGBUILDs yourself" advice is not a reliable defense at scale.

Immediate actions for Arch Linux users:

Audit every AUR package installed or updated since July 29, 2026. Run pacman -Qm to list all foreign (AUR) packages installed on your system and cross-reference against the community tracking list being maintained on the Arch mailing list and the tracking thread . If any package on your system appears on the list, or if you installed or updated AUR packages in that window from a source you cannot now independently verify, assume compromise.

If your system is potentially compromised:

Treat any system where a flagged package was built as fully compromised — not merely at risk. Rotate all credentials immediately: every browser-stored password, every SSH private key (generate new keys and replace authorized_keys entries on every reachable system), every cloud provider API key, every AI service API key, every CI/CD pipeline secret, every cryptocurrency wallet (move assets to a new wallet generated on a clean device). Because the SSH worm may already have pivoted to other systems using your stolen keys, coordinate credential rotation across your entire infrastructure, not just the affected workstation.

The SSH worm propagation risk requires infrastructure-wide response. A compromised Arch developer machine is not an isolated endpoint incident. Any system in your SSH trust graph — servers you can reach with ssh — must be audited. Review SSH authorized_keys on every machine that accepted connections from the potentially compromised workstation in the period since July 29. Revoke old keys and generate fresh ones.

Systems where malicious packages were executed with elevated privileges (i.e., where sudo makepkg was used) should be treated as potentially irreversibly compromised and rebuilt from trusted installation media.

Until the adoption mechanism is restored and Arch Linux has published a structural response — cryptographic PKGBUILD signing, automated behavioral analysis, mandatory maintainer verification, or similar — treat every AUR package update as a potential risk. For critical systems, consider disabling AUR package installation entirely pending a structural fix.

The Atomic Arch campaign has now run three waves over roughly seven weeks, each wave adapting specifically to the detection mechanism Arch deployed against the one. That pattern reveals something beyond the immediate incident: the AUR's trust model — open adoption of orphaned packages, PKGBUILD execution on install, community vetting as the primary defense — is structurally incompatible with an adversary who is actively iterating against the defenses.

The same attack pattern extends to npm, PyPI, Homebrew , and every other community-maintained package repository that allows third-party code execution at build or install time. The AUR's exposure is more acute because Arch Linux's user base skews toward developers and CI/CD environments — the same high-value targets the June wave's npm-staged payload was specifically tuned to reach.

The question the adoption freeze doesn't answer is what comes after: whether the AUR will introduce mandatory behavioral sandboxing of PKGBUILDs, cryptographic signing of build scripts, automated anomaly detection for newly adopted packages, or stricter account vetting. Temporary freezes contain active campaigns; they do not fix the architecture that makes the campaigns possible.

Run pacman -Qm to list all foreign packages currently installed on your system — these are packages not from official repositories and typically come from the AUR. Compare the output against the community tracking list being maintained on the Arch Linux aur-general mailing list and the thread at r/archlinux. Also review your package manager logs ( /var/log/pacman.log ) for any AUR package install or update activity since July 29, 2026. If you used an AUR helper like yay or paru , check its log files as well. If any flagged package appears, treat the system as fully compromised regardless of whether your antivirus or endpoint tool reports anything — the first-stage loader performs sandbox detection and may have reported clean in automated scans.

SSH authentication relies on private/public key pairs. Your private key, stored in ~/.ssh/ , can authenticate you to any machine where your corresponding public key appears in an authorized_keys file — a server you deploy code to, a colleague's machine you have access to for collaboration, a cloud instance, a backup host, or a CI/CD runner. When the Wave Three infostealer copies your SSH private key, it also reads your known_hosts file (which lists machines you've previously connected to) and uses the stolen keys to reach those machines, copy itself there, and execute — without any password prompt, without any visible sign of intrusion, and without requiring the attacker to know anything your infrastructure in advance. Your SSH trust graph is a map of everything attackers can reach from your machine, and they now have the keys to all of it.