CVE-2026-48754 in incus
Summary
by MITRE • 08/21/2026
Incus is a system container and virtual machine manager. Prior to version 7.1.0, `(*backend).createDependentVolumesFromBackup` in `internal/server/storage/backend.go` contains a cluster of unguarded pointer derefs on every dependent-volume entry's `VolumeSnapshots[i]`, `Volume`, and `Pool` sub-fields. An authenticated user with `can_create_instances` permission on any project can crash the `incusd` daemon by uploading an instance backup tarball whose `dependent_volumes[*]` block contains a nil snapshot pointer (or omits `volume:` / `pool:`). This is a sibling-field variant of the 2026-05-04 batch fix `d768f81c0a1d985f35ae56219519822b080bf5e3` ("Properly check dependent volumes on import"). That commit added `if disk == nil` at the top of the outer loop, but did not guard the four sub-pointer fields the loop body dereferences naked. Version 7.1.0 contains an updated patch.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
Incus is a system container and virtual machine manager that provides infrastructure for managing Linux containers and virtual machines. The vulnerability identified in versions prior to 7.1.0 resides within the internal server storage backend, specifically in the function responsible for creating dependent volumes from backup archives. This component handles the restoration of instance backups, which are typically distributed as tarballs containing metadata and volume data. During this process, the system parses a list of dependent volumes associated with the primary instance to ensure all related storage components are correctly reattached or recreated. The core technical flaw involves unguarded pointer dereferences on critical sub-fields within each dependent-volume entry in the backup structure. Specifically, the code attempts to access nested fields such as VolumeSnapshots[i], Volume, and Pool without verifying that these pointers are non-nil before use.
The operational impact of this vulnerability is a denial of service against the Incus daemon process. An authenticated user who possesses the can_create_instances permission on any project within the system can exploit this flaw by uploading a maliciously crafted instance backup tarball. By manipulating the dependent_volumes block in the backup metadata to include entries with nil snapshot pointers or omitting required volume and pool fields, the attacker triggers an unhandled panic when the daemon attempts to dereference these null references during the import process. This results in the immediate crash of the incusd service, disrupting availability for all users relying on that instance until the service is manually restarted. The vulnerability represents a sibling-field variant of a previously addressed issue from May 2026, where an initial fix added nil checks at the top of the outer loop but failed to protect against dereferences occurring deeper within the loop body's logic flow.
From a security classification perspective, this flaw aligns with CWE-476, which denotes a NULL Pointer Dereference vulnerability. The attack vector is classified under MITRE ATT&CK technique T1529, specifically System Shutdown or Reboot, as the exploitation leads to service unavailability through process termination. Although the requirement for authentication and specific project permissions limits the scope of potential attackers compared to remote code execution vulnerabilities, it remains a significant risk in multi-tenant environments where users may have elevated privileges within isolated projects but lack full system administration rights. The vulnerability highlights the importance of defensive programming practices when handling external data structures that are deserialized from untrusted sources like backup archives.
Mitigation for this issue is straightforward and involves upgrading to Incus version 7.1.0 or later, which contains a patch addressing these specific pointer dereferences. In environments where immediate upgrade is not feasible, administrators should enforce strict access controls on the can_create_instances permission, ensuring that only trusted users with verified backup sources are granted such privileges. Additionally, implementing input validation at the API layer to reject malformed dependent volume structures before they reach the storage backend logic could provide an additional layer of defense against similar future vulnerabilities in other components handling serialized data.