Arch Linux 2026.09.01 ships kernel 7.2.2 and puts AUR vigilance back at the center
On September 1, 2026, Arch Linux published its monthly 2026.09.01 ISO, the first image to carry a 7.2-series kernel. For existing users there is nothing to download: upgrades flow through pacman, and the real risk lives in the AUR and the infrastructure transitions.
September 1, 2026. Arch Linux publishes its monthly snapshot 2026.09.01. 7.2.2. That is the kernel it carries, the first appearance of a 7.2 series on a monthly ISO. 1.5 GB. That is the image size, meant for fresh installs only. Why it matters: on a rolling release, the ISO is not a version to install — it is a health check of the ecosystem, and August’s reveals transitions that bite far harder than the kernel number.
The ISO as a snapshot of the rolling release
Recall the mechanics of Arch Linux to read this release correctly. Unlike Ubuntu or Fedora, there is no major version to upgrade: the system moves continuously, and pacman -Syu keeps an installation current indefinitely. The monthly ISO only exists to lay down a fresh system, with a coherent package set at burn time.
What the 2026.09.01 snapshot freezes is an Arch that moved in August to kernel 7.2.2 — built on August 28 — where the July ISO carried 7.1.5. It is the first time a 7.2 branch kernel appears on an install image. Behind that number, the whole stack moved: GCC 16.2.1, glibc 2.44, Python 3.14.7, and mkinitcpio 41.1 form the base, completed by OpenSSH 10.5p1, OpenSSL 3.6.4, and iproute2 7.2.0.
Graphics and virtualization follow
The graphics side saw a substantial refresh. Mesa 26.2.1 arrives with its Vulkan drivers for AMD, Intel, Nouveau, Panfrost, and Freedreno. On the NVIDIA side, the repositories moved to the 610.57.04 series with the nvidia-open, nvidia-open-dkms, and nvidia-open-lts variants. On the desktop, KDE Plasma 6.7.4, KDE Frameworks 6.29, GNOME Shell 50.4, and COSMIC Desktop 1.7 are in place, alongside LibreOffice 26.8, Firefox 154, Chromium 152, and Vivaldi 8.1.
For the self-hoster, the rest of the snapshot matters more: QEMU 11.1, libvirt 12.6, VirtualBox 7.2.16, and above all Docker 29.7.2, Docker Compose 5.5, containerd 2.3.4, and Podman 6.1. An Arch machine serving as a virtualization box or container host receives the bulk of its tools up to date here, with no action beyond the usual pacman -Syu.
What a dated ISO is worth
Beyond installation, a monthly ISO is a reproducibility tool. Burning 2026.09.01 guarantees starting from a precise state — kernel 7.2.2, glibc 2.44, GCC 16.2.1 — rather than a rolling state captured at some moment by pacman. That matters when you deploy several identical machines or document a procedure another team will have to replay six months later. The dated image becomes a reference point, not just an installer. And that regularity is no accident: the project, born in 2002 and still active in 2026, has kept this monthly cadence for twenty-four years. For a homelab that rebuilds hosts from a flash drive, that consistency is worth more than the kernel number itself.
The three transitions that actually bite
The kernel number draws the eye, but three infrastructure changes — all predating August — keep breaking installs for users who discover them at the worst moment. First: the default iptables backend moved to nftables in April, and anyone restoring old iptables-based firewall scripts runs into a system that no longer applies them as written. Second: NVIDIA dropped Pascal and older GPU support with driver 590 and moved its main packages to the Open Kernel Modules — a change that hits dual-GPU machines and proprietary configurations. Third: the Varnish package was renamed vinyl-cache in May, which silently breaks any dependency or script targeting the old name.
None of these transitions is new in September, but their accumulation inside a single monthly snapshot makes this the right moment to inventory them. That is the value of a dated ISO: it provides a stable comparison point for measuring what the distribution actually moved.
The AUR as the real supply-chain risk
The most important signal in this release is not strictly technical: it is the reminder, made by Linux Compatible in its roundup, of the June malicious-package incident in the AUR. Malicious package takeovers were detected, with a high volume of suspicious adoptions and updates. The AUR now holds over 49,000 build scripts against roughly 15,770 official packages — a ratio that makes manual review of every PKGBUILD hard, and blind trust dangerous.
# Existing users: the rolling release flows through pacman, not the ISO
sudo pacman -Syu
# For the AUR: read the PKGBUILD before building, not just the latest version
makepkg -siThe discipline fits in one rule: any package pulled from the AUR is third-party code to audit like a vendor. Read the PKGBUILD, check the download source, and pin the versions you have validated. The project, led by Levente Polyák re-elected on June 4, 2026, has disabled risky package adoptions, but the surface remains wide.
The mechanics of an AUR package takeover
The AUR risk is not theoretical. The attack pattern observed in June is simple: an orphaned package — one whose maintainer has abandoned it — is adopted by a new account, which injects malicious code into the PKGBUILD or an install script, then publishes an update. Users who upgrade without reading receive the compromised code as a legitimate version. It is a classic supply chain, applied to a distribution where review is entirely delegated to the end user.
The project’s response was to disable risky package adoptions in late July, but the underlying mechanism remains: the AUR is a community collection where nobody guarantees the content. The defense is a routine the tooling makes easy — paru and yay display the PKGBUILD diff before building, and it is that diff you must read, not the package name.
# Read the PKGBUILD and its sources before building
paru -Syu --devel # shows the diffs to approve one by one
# Check the active firewall backend (iptables -> nftables transition)
nft list ruleset | head -20The iptables to nftables transition deserves the same reflex: an old script that calls iptables directly may still work through the compatibility layer, but it is safer to confirm the rules are actually applied by nft. On the NVIDIA side, a pacman -Q | grep nvidia shows whether you are on nvidia-open or still on the legacy package; Pascal and older cards are frozen below driver 590 and force you to plan a migration or a version freeze.
The broader lesson is that a rolling release shifts the security burden from the vendor to the operator. A fixed-release distribution hands you a patched base and a frozen package set maintained upstream; Arch hands you a moving target in exchange for freshness, and you are the one who audits what enters it. That is why the AUR review habit — reading the diff, pinning versions, checking download sources — is not optional hygiene but the actual security control, and why pacman -Syu on a box you never inspect is a gamble rather than a patch.
Verdict
If you are installing Arch fresh, take the 2026.09.01 ISO: it carries a 7.2.2 kernel and a coherent stack, and the archinstall installer has greatly smoothed setup. This is the image to burn, not the old one.
If you are already on Arch, download nothing: pacman -Syu puts you in the same state. Spend the time you saved on two checks instead — that your firewall rules have actually moved to nftables, and that your AUR packages have reviewed PKGBUILD files and pinned versions.
If you manage a fleet of Arch machines, plan the NVIDIA move to open modules and the Varnish rename before a broad upgrade: those silent changes, more than the kernel, are what cause upgrade outages.