Incus administrators should treat Incus 7.2 as a priority security maintenance release, especially on shared hosts, agency infrastructure, lab clusters, and any environment where multiple users, projects, images, or client workstations interact with the same Incus estate.
The Incus project published Incus 7.2 on June 26, 2026. The release notes state that it fixes eight security issues: six critical and two high. The public GitHub advisories list versions before v7.2.0 as affected and v7.2.0 or later as patched for the Incus server package.
This is not a routine feature-only update. The fixed issues touch host file access and write risk, restricted project isolation, backup handling, client trust, and cross-project copy behavior. For hosting providers, homelab operators, MSPs, and teams using Incus as a container or VM management plane, those are control-plane and tenant-boundary topics.
Who Should Act
Review this update if you run Incus servers, Incus clusters, remotely managed Incus hosts, project-restricted environments, customer-facing container or VM platforms, CI or build systems that import images, or admin workstations with trusted Incus remotes.
Pay particular attention if your environment allows multiple administrators, multiple projects, delegated project access, customer-supplied images, automated image intake, backup/export workflows, custom storage volumes, or instance copies between projects.
Affected And Fixed Versions
The Incus advisories list affected versions as earlier than v7.2.0 and patched versions as v7.2.0 or later. If your distribution backports fixes, verify the vendor package advisory or changelog instead of relying only on the upstream version number.
Incus upstream notes that it publishes release tarballs rather than official universal packages. Operators should use the package source they already trust for their platform, then confirm that the installed build includes the relevant Incus 7.2 security fixes or a vendor-backed backport.
Security Issues Fixed In Incus 7.2
The upstream release links the following public advisories:
- CVE-2026-48749 – critical host file access/write impact from malicious image handling.
- CVE-2026-48750 – critical host file write impact from crafted image handling.
- CVE-2026-48751 – critical restricted project isolation failure with command execution impact.
- CVE-2026-48752 – critical host file access/write impact from malicious image handling.
- CVE-2026-48755 – critical backup handling issue with file write and command execution impact.
- CVE-2026-48769 – critical client-side file write impact tied to trusted image handling.
- CVE-2026-55621 – high project restriction issue affecting custom volume copy boundaries.
- CVE-2026-55622 – high project restriction issue affecting instance copy boundaries.
I am keeping the Fix I.T. Phill guidance protect-only here. Use the official advisory links for affected-version confirmation and vendor status, but do not circulate test artifacts or reproduction details in tickets, customer notices, or public runbooks.
Patch Planning Checklist
Before updating, make a current inventory of Incus servers, clusters, storage pools, projects, remote clients, and automation that talks to Incus. Identify which systems can be updated immediately and which require a maintenance window because they host customer workloads, persistent storage, or clustered services.
Take a backup or snapshot appropriate for the host role before changing packages. For clustered environments, verify quorum, storage health, and migration capacity first. Drain or live-migrate workloads where your design supports it, and avoid changing every cluster member at once unless your operational model already supports that approach.
After updating, confirm that the Incus server build is patched, that API access still works only from expected networks or VPNs, that project restrictions still match your tenant model, and that existing containers and virtual machines start cleanly. Check storage pool status, backup jobs, image import workflows, and any automation that copies instances or volumes between projects.
Hosting And Tenant Isolation Review
For providers and agencies, the important question is not just whether the package is patched. Review who can import images, create instances, copy instances, copy custom volumes, trigger backups, or trust remote image sources. Those permissions should match your customer boundary, not just your internal convenience model.
If you expose Incus through a remote API, portal, VPN, automation runner, or customer-facing service layer, verify the management plane separately from the workload plane. Limit trusted clients, rotate stale credentials, review certificates and tokens, and confirm that customer-controlled inputs cannot reach privileged host workflows without review.
Also check administrator workstations. One of the advisories affects client-side trust behavior, so operators should update both servers and trusted client machines where they manage Incus remotes or interact with shared image sources.
Compatibility Notes
Incus 7.2 also includes operational changes that may matter during maintenance. The release highlights per-instance SELinux integration, filtered server information by default, and client configuration location changes on macOS and Windows. These are useful improvements, but they can affect scripts, documentation, and screenshots that assumed the older output or local client paths.
Monthly Incus feature releases are supported only until the next monthly release. If your business prefers a slower maintenance lane, compare your vendor packages and support model against the current Incus LTS track, then document which channel you want production hosts to follow.
Post-Update Verification
After the maintenance window, verify these outcomes before closing the ticket:
- Incus servers and admin clients are on a patched build or a vendor-confirmed backport.
- Cluster members are healthy and workloads restarted or migrated as expected.
- Project restrictions still enforce the intended customer and team boundaries.
- Image import, backup, restore, instance copy, and custom volume copy workflows behave as expected for authorized users only.
- Storage pools, snapshots, and scheduled backups report clean status.
- Remote API exposure, VPN rules, certificates, tokens, and admin workstation access have been reviewed.
- Customer communication is complete if hosted workloads, portals, or managed environments were affected by the maintenance window.
Bottom Line
Incus 7.2 deserves prompt attention on any host where Incus is more than a single-user lab tool. Patch to v7.2.0 or a vendor-confirmed fixed build, then verify tenant isolation, trusted image workflows, backup paths, and client workstations. The risk profile is highest where Incus is used as a shared control plane.
Sources
- Linux Containers: Incus news
- Incus 7.2 release announcement
- GitHub advisory GHSA-2q3f-q5pq-g8wv
- GitHub advisory GHSA-73hr-m85f-64v9
- GitHub advisory GHSA-48q5-w887-33wv
- GitHub advisory GHSA-vxp5-584q-c479
- GitHub advisory GHSA-v6mj-8pf4-hhw4
- GitHub advisory GHSA-f6m5-xw2g-xc4x
- GitHub advisory GHSA-64f3-v33m-w89f
- GitHub advisory GHSA-c9f5-j9c3-mhrg
