Arch Linux disabled AUR package adoption to stop a malware flood

Arch Linux temporarily disabled package adoption in the Arch User Repository (AUR) after a flood of malicious takeovers. Attackers adopted orphaned packages and injected malicious code into build files, reaching over 200 packages. It is a manual supply-chain attack: the users were not breached — the source they installed from was. Below: how it worked and what to take away if you depend on community repositories.

In brief

• Arch contributor Robin Candau announced: “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.”
• Attackers adopted orphaned packages or compromised maintainer accounts, then injected code into the build files.
• The campaign started on 29 July 2026 (first package: openconnect-sso) and spread to over 200 packages.
• Two-stage malware: an anti-analysis loader + a Rust-based infostealer, delivered over Tor.
• Targets: SSH keys, cloud/dev secrets, API keys (including AI services), crypto wallets, passwords.
• The measure is temporary, pending a permanent solution (no timeline announced).

How the AUR was abused

The AUR is community-maintained: users can adopt orphaned packages (abandoned by their original maintainer) or take over existing ones. It is useful — and it is exactly the vector. Attackers took over orphaned packages or compromised maintainer accounts, then modified the build files (PKGBUILD). From that point, anyone installing the package ran the attacker’s code themselves, with their own session’s privileges.

Packages identified as affected: boringssl-git, icloudpd, windscribe-cli-v2-bin, stirling-pdf-desktop-bin, openconnect-sso, arduino-language-server-noclang-bin, pgadmin4-server.

What the malware does

The chain has two stages:

• Stage 1 — anti-analysis loader. It checks whether it is running under a debugger, sandbox, virtual machine or CI/CD (so it does not expose itself in analysis labs). It establishes persistence via systemd services and cron, then downloads a Tor client disguised as “dbus-daemon” to fetch the second stage from a .onion server.
• Stage 2 — Rust infostealer. It steals browser credentials, crypto wallets, password-manager data, cloud/dev secrets, AI-service API keys, SSH keys and messaging tokens. It provides remote command execution over encrypted Tor and lateral movement using the stolen SSH keys.

The detail that matters: this is not a shallow, opportunistic attack. It is anti-analysis, persistent, Tor-encrypted, and it hunts exactly what a development team holds — keys, secrets, access to infrastructure.

Not the first wave

IFIN’s analysis notes similarities to an earlier campaign: in June 2026, over 400 AUR packages had been compromised to distribute a rootkit and an infostealer, with the same tactics, including using the Tor network for staging. The pattern repeats — community repositories remain an attractive attack surface.

What to take away

• Community ≠ vetted. The AUR (like npm, PyPI, browser/IDE extensions) is unvetted supply chain. “Adopting” orphaned packages is a useful mechanism attackers use as a door.
• Read what you install. For the AUR, the build file (PKGBUILD) is visible — read it before you build. Pin versions and avoid opaque binaries (-bin) where you can.
• The developer workstation is a target. The infostealer hunts SSH keys, cloud secrets and API keys. Least privilege, secret rotation and environment separation limit what a single compromise can steal.
• Detection is behavioral, not signature-based. The loader evades sandboxes and uses Tor to .onion. Egress and behavior monitoring catch what signature-based antivirus misses.

Our recommendations

If your team depends on external packages and developers run third-party code, here is where we would start:

• Supply-chain and secrets audit. We inventory where your dependencies come from, how they are pinned and verified, and how exposed keys and secrets are on development workstations and in build pipelines. Part of the security audit.
• Security testing. A penetration test checks not just the application but the build-and-delivery chain — exactly where a compromised package enters.
• Continuous security. An upstream maintainer can be compromised at any time; monitoring and periodic review catch unusual execution and suspicious egress when it happens.

Want to know how exposed your dependency chain is, and what a single compromised workstation could steal? Get in touch and we start with an audit.