CVE-2026-48754 is a low-severity null pointer dereference vulnerability in github.com/lxc/incus/v7/cmd/incusd (go), affecting versions < 7.1.0. It is fixed in 7.1.0.
Summary (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 cancreateinstances permission on any project can crash the incusd daemon by uploading an instance backup tarball whose dependentvolumes[] 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. Vulnerable code internal/server/storage/backend.go:9352-9412: disk has type config.Config (declared in internal/server/backup/config/backupconfig.go:8). Its Volume field is api.StorageVolume, Pool is api.StoragePool, VolumeSnapshots is []api.StorageVolumeSnapshot, all yaml omitempty. YAML omission decodes to nil for each. The parent fix mental-modeled "outer-iteration variable nil"; it did not walk every sub-field deref inside the loop body. Direct asymmetric-guard variant. Reach Attacker is an authenticated client with cancreateinstances on any project. Same auth gate as GHSA-8g7m-96c8-8wwc / CVE-2026-47753. POST /1.0/instances with Content-Type: application/octet-stream and X-Incus-name: <name>. Body is a tar containing backup/index.yaml whose config: block has a non-nil container: (passes instancespost.go:854 if bInfo.Config == nil || bInfo.Config.Container == nil) and a dependentvolumes: list with a malformed entry. Chain: instancesPost -> createFromBackup:854 (Container guard passes) -> pool.CreateInstanceFromBackup -> backend.go:782 b.createDependentVolumesFromBackup -> backend.go:9374 snap.Name panics on the nil *api.StorageVolumeSnapshot element. incusd dies. Persistent DoS on repeat. Minimal backup/index.yaml (used in the bundled PoC): (The container block must declare at least one device with type: disk, dependent: "true", pool != "", path != "/" to populate devicesMap and reach the second loop. Trivially satisfiable.) An equivalent triggering YAML omits volume: or pool: from the dependentvolumes entry; in that case disk.Volume.Project at 9378 panics instead. Proof of concept (end-to-end against running daemon) Bundled in the report: makebackup.sh + 666-byte poc-inst.tar.gz. Tested against incus 7.0.0 (zabbly latest GA, build 1:0~ubuntu24.04~202605201355) inside a privileged Ubuntu 24.04 container with default dir pool. Daemon panic: Stack frame backend.go:9374 is the literal snap.Name line. Impact Severity: denial of service against the entire incusd process. Every container / VM / storage operation on the host (and on the cluster member, if clustered) is aborted; subsequent requests fail until an operator restarts the process. Privileges required: any authenticated user with cancreateinstances on any project. Not behind the admin tier. Network attack surface: the Incus REST API on :8443 or the unix socket. CWE-476, Nil-Pointer Dereference. CVSS estimate: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). Versions: v7.0.0 confirmed. The dependentvolumes feature did not exist in v6.x, so the vulnerable code is v7-only. Suggested fix Reporter notes Reported via Privately-Reported Vulnerability against lxc/incus by tonghuaroot.
The application dereferences a null pointer, causing a crash. Typical impact: denial of service via crash.
go
github.com/lxc/incus/v7/cmd/incusd (< 7.1.0)github.com/lxc/incus/v7/cmd/incusd → 7.1.0 (go)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-48754 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-48754 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-48754 in your environment →Upgrade github.com/lxc/incus/v7/cmd/incusd to 7.1.0 or later to resolve this vulnerability.
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-48754 is a low-severity null pointer dereference vulnerability in github.com/lxc/incus/v7/cmd/incusd (go), affecting versions < 7.1.0. It is fixed in 7.1.0. The application dereferences a null pointer, causing a crash.
github.com/lxc/incus/v7/cmd/incusd (go) versions < 7.1.0 is affected.
Yes. CVE-2026-48754 is fixed in 7.1.0. Upgrade to this version or later.
Whether CVE-2026-48754 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
Upgrade github.com/lxc/incus/v7/cmd/incusd to 7.1.0 or later.