Arch Linux temporarily disabled all pushes to the Arch User Repository (AUR) on August 1 after first blocking package adoption during a new wave of malicious takeovers. The confirmed current case starts with openconnect-sso, whose poisoned build path delivered a Linux loader followed by an infostealer, remote-access trojan, and SSH worm. AUR is a community repository, not the official Arch package repository, but anyone who built or updated an affected AUR package must check the host rather than assume the repository freeze removed code that already ran.
The Arch DevOps team announced the adoption block on July 30 and expanded it to all AUR pushes on August 1 while the incident was handled [1]. Independent Federated Intelligence Network (IFIN) identifies openconnect-sso as the first confirmed package in the current wave and says its malicious commit was reverted [2]. A revert prevents a new build from using that exact commit; it cannot undo a package that was already built or executed.
Who needs to check an Arch system?
| Situation | Risk and next decision |
|---|---|
| You use only official Arch repositories | The documented entry path is AUR, so this specific package-adoption incident does not apply. Confirm that no AUR helper or manual AUR build was used. |
| You use AUR but did not update around July 29-August 1 | Review package and helper history before assuming there was no exposure. The public incident scope is still developing. |
openconnect-sso was built or updated in that window |
Treat the package as exposed. Check the exact AUR commit/build files and look for loader or persistence artifacts. |
| The package build or payload executed | Isolate the host and treat browser data, password managers, wallets, cloud credentials, API tokens, messaging sessions, and SSH keys available to it as potentially exposed. |
| Loader or second-stage indicators are present | Preserve evidence, remove the host from trusted build/deployment work, rebuild from trusted media, and rotate secrets from a clean system. |
Do not turn an unverified community list into a diagnosis. Public posts allege that many more packages were involved, but Arch has not published a complete affected-package list for this wave. One confirmed package and the official push shutdown are enough to justify targeted review; they are not evidence that every AUR package or every Arch machine is infected.
What the confirmed AUR payload does
The analyzed first stage is a stripped Linux x86-64 loader. It checks for debuggers, sandboxes, cloud environments, and CI variables; then it can copy itself into a system or hidden user location and create persistence through systemd units, user lingering, and cron. It downloads a Tor bundle from the legitimate Tor archive, launches it with the process name dbus-daemon, and retrieves the second stage from an onion service [3]. The use of a legitimate Tor download host is not proof by itself; the suspicious sequence is an unexpected download, disguised Tor process, persistence, and the follow-on payload.
The second-stage analysis describes a credential stealer, interactive RAT, and SSH worm. It searches browser profiles, password-manager data, cryptocurrency wallets, messaging sessions, cloud and Kubernetes configuration, package-registry credentials, Git tokens, AI-service keys, and SSH material. It can use stolen SSH keys and known hosts to copy and execute itself on other systems [4]. That is why a developer workstation or build runner can create a larger incident than the first affected laptop. The same trust boundary appears in QLNX attacks on Linux developer and cloud credentials, although the delivery and persistence mechanisms differ.
Artifacts worth checking
| Artifact | Why it matters |
|---|---|
AUR helper history and /var/log/pacman.log |
Establish whether openconnect-sso or another newly adopted AUR package was built or installed during the incident window. |
Unexpected system or user systemd units named only .service |
The analyzed loader uses systemd persistence and can enable user lingering so it survives logout. |
New @reboot entries or unfamiliar files launched by cron |
The loader uses cron as a redundant persistence path. |
Tor launched as dbus-daemon |
The loader disguises its Tor process. A normal system dbus-daemon is common, so correlate the executable path, parent process, network activity, and start time. |
/dev/shm/.agent.bin or unexplained hidden executables |
The public analysis identifies this as a second-stage staging artifact, but absence does not prove a host is clean after files were removed. |
| Unfamiliar SSH activity or deployments | The second stage can reuse stolen SSH keys to spread to systems listed in known-hosts data. |
Hashes from IFIN are useful for matching known samples, but hash-only scanning is not enough. The report warns that it is too early to know how common the identified hashes are, and random file names reduce the value of one fixed path. Correlate package history, process execution, persistence, network activity, and credential use.
Response order after a suspicious AUR update
- Stop further execution. Pause automatic AUR helper runs. Do not delete the package cache or logs before recording the package version, AUR commit, build directory, timestamps, and hashes.
- Confirm the state. Separate “the package appeared in history,” “it was built,” “the build script ran,” “the loader ran,” and “the second stage is present.” These are different evidence levels.
- Isolate an affected host. Disconnect it from sensitive networks and remove it from CI, signing, package publishing, and deployment paths. Do not use it to change passwords or generate replacement keys.
- Preserve useful evidence. Save package/helper history, pacman logs, system and user unit definitions, cron entries, process and network data, shell history, recent SSH activity, and cloud identity logs before cleanup.
- Re-establish host trust. For confirmed loader or second-stage execution, a trusted rebuild is safer than deleting only the visible package and random-looking files. Verify every downstream build artifact produced during the exposure window.
- Rotate secrets from a clean device. Revoke browser sessions, password-manager sessions, Git and package-registry tokens, cloud/API credentials, wallet access where applicable, and SSH keys reachable from the host. Remove old SSH public keys from servers, not only the private key from the laptop.
- Hunt for lateral use. Review SSH authentication, repository activity, package publications, cloud actions, CI jobs, and new tokens after the earliest possible execution time.
- Resume AUR use cautiously. Check the current Arch incident thread for a follow-up, review
PKGBUILDand install-file changes, verify upstream sources and checksums, and avoid treating a familiar package name as proof of a trusted maintainer.
The response order follows the same principle as other poisoned package incidents: remove malicious persistence and restore a trusted execution environment before exposing replacement credentials to the machine.
References
- Robin Candau, Arch Linux DevOps. “AUR packages adoption disabled.” Arch Linux aur-general mailing list, published July 30, updated August 1, 2026, accessed August 2, 2026. official incident thread.
- Matt Taggart. “New AUR Attack Prompts Adoption Lock.” Independent Federated Intelligence Network, published July 30, updated July 31, 2026, accessed August 2, 2026. current-wave report and indicators.
- ysf. “AUR validator.malware (stage 1).” GitHub Gist, created July 29, 2026, accessed August 2, 2026. loader analysis.
- ysf. “AUR validator.malware (stage2 agent linux x86_64).” GitHub Gist, created July 30, 2026, accessed August 2, 2026. second-stage analysis.
