Arch Linux freezes AUR signups after attackers poison packages

Arch Linux maintainers disabled new account registration for the Arch User Repository on Monday, June 15, 2026, after attackers flooded the community package service with poisoned adoptions and updates.

The project first warned users June 12 that attackers had targeted the Arch User Repository, known as AUR, with a high volume of hostile package activity. Maintainers said users could face trouble creating accounts, pushing updates, adopting packages, and creating packages while the team cleaned up the repository.

The count grew from about 400 affected packages to more than 1,500 over the weekend. Maintainers spotted a more advanced wave June 14, then blocked new AUR registrations Monday morning while they removed hostile changes.

Arch maintainers have not reported a compromise of the core Arch Linux distribution. Users should treat the incident as an AUR supply chain event that affects user-submitted package build scripts, not the signed package sets that Arch maintains in its main repositories.

AUR gives Arch users access to software that Arch maintainers do not package in the main repositories. That reach makes it useful, but it also puts more responsibility on users. The ArchWiki AUR guidance tells users to inspect package build files before installation because AUR packages come from the community.

The hostile packages tried to pull in JavaScript dependencies from npm. That choice matters because many AUR packages execute build instructions from a PKGBUILD file. If an attacker controls the package recipe, the attacker can tell the user's machine to fetch extra code during build or install steps.

A careful user should inspect the PKGBUILD, .install files, patch files, and source URLs before running an AUR helper. The PKGBUILD documentation explains the fields that define sources, checksums, build steps, and install commands. A hostile package can hide risk in any of those places.

AUR helpers add another concern. Tools that automate package search, build, and update workflows can make AUR feel like a standard package manager. That convenience can hide the review step. During a campaign like this, users should avoid blind upgrades and read the build files for packages updated since June 12.

Compliance and security teams that allow Arch Linux on developer workstations should take three steps now. First, they should inventory systems that install AUR packages. Second, they should review package update logs for AUR activity between June 12 and June 15. Third, they should remove or rebuild packages that match the affected window once Arch maintainers publish a final cleanup list.

Teams should also search developer machines for unexpected npm packages, new network calls during package builds, and changes under user build directories. AUR packages often compile software in temporary build paths, so responders should collect shell history, AUR helper logs, package cache entries, and recently modified files before they wipe evidence.

Organizations can reduce repeat exposure by separating official Arch packages from AUR packages in policy. Developers can use pacman for official repositories and require manual review for AUR builds. Security teams can also mirror approved AUR package recipes, pin commit hashes, and require checksums that match reviewed sources.

The incident fits a wider supply chain pattern. Attackers look for package ecosystems that let them publish code fast, take over abandoned projects, or hide payloads in install scripts. AUR gives them a large target because it hosts more than 107,000 packages and saw more than 5,500 package updates in the past seven days.

Arch users should watch the AUR website and Arch project channels for cleanup status. New account creation remained disabled at publication time, and maintainers said they would keep working through the affected packages.

Until Arch maintainers finish cleanup, users should pause nonessential AUR installs, inspect recent upgrades, and rebuild trusted packages from reviewed recipes. For teams that manage developer fleets, the safest near-term control is simple: treat AUR packages as source code from the internet and require review before execution.