The Arch User Repository is a community run, opt in collection of user built software packages separate from Arch's official repos, so exposure depends on whether a user installed an AUR helper, and on how Arch derivatives like Manjaro and EndeavourOS cached the affected builds.
The Arch User Repository, a community-run, opt-in collection of user-submitted software packages that sits outside Arch Linux's official repositories, absorbed a wave of malicious commits on 12 June 2026, with the running tally of affected packages climbing from roughly 400 to 900 to 1,579 over the course of a single day. Arch maintainers say they have reverted the commits they know about, but their own advisory describes the list as containing "many (but not all)" of the affected packages, a caveat that turns the day's "under control" framing into a partial containment at best.
The escalation, not the resolution, is the news. According to Phoronix's same-day writeup of the Arch Linux security incident thread, the count moved three separate times on Friday, and each upward revision was paired with the maintainers' continued characterization that the situation was being brought under control, even as the scope kept growing (Phoronix).
What "under control" actually covers is narrower than the phrase suggests. The Arch maintainer thread, which is the primary record of the incident, frames the cleanup as targeting the malicious commits the team has identified, not as a guarantee that no further affected packages will surface. The 1,579 figure, in other words, is a count of what the maintainers have found and reverted so far, not a confirmed total. For readers on Arch or an Arch derivative such as Manjaro or EndeavourOS, the practical question is not whether the maintainers believe they have contained the incident, but whether any of the affected builds were cached and served to users during the window the malicious commits were live.
The AUR is opt-in, and that distinction matters for blast radius. A user who installed Arch and stayed with the official repositories, or who uses a derivative that mirrors only the official repos, is not directly exposed to the AUR compromise. A user who installed an AUR helper, such as yay, paru, or a manual makepkg workflow, and who pulled or built any of the affected packages during the window the malicious commits were live, is in the at-risk set, even if their system shows no obvious symptoms. Arch derivatives inherit the AUR's exposure in proportion to their caching lag, since they typically pull AUR material downstream rather than from the AUR directly.
Several pieces of the picture are still missing. Phoronix's reporting does not enumerate the attacker vector, the type of malicious payload, or whether any telemetry from installed systems shows real-world impact (Phoronix). The Arch maintainer thread, which is the primary source for those details, had not, as of Phoronix's last update, released a finalized list of malicious commit hashes, the accounts that submitted them, or the exact download and install window during which the affected builds were served. The "under control" framing is the maintainers' own characterization, reported as such, and it should be read alongside the "many (but not all)" qualifier in their own advisory.
For a user who does use the AUR, the concrete next step is bounded: audit recent builds against the maintainer thread once the commit hashes are posted, watch for hash and signature mismatches on cached packages, and hold off on any AUR updates that have not been independently verified until the list is closed out. For everyone else, the structural lesson is the part worth keeping. A trust-by-reputation software repository, in which any user can submit a package and any other user can install it, is the model the AUR has run on for years, and this incident is what that model looks like under active stress. The escalation arc, three numbers in a single day with the final figure explicitly incomplete, is the honest headline inside the optimistic one.