Incus vulnerabilities

Incus before version 7.2.0 has missing authorization checks for instance copying, allowing an attacker who knows the name of a project and an instance in that project to copy the instance to a new project.

Incus prior to version 7.2.0 has missing authorization checks for custom volume copying. An attacker knowing the name of a project they don't have access to and the name of a custom volume in that project can copy the volume to a new project. This could allow access to secrets in volumes they are not authorized to access.

Incus before version 7.1.0 has a nil-pointer dereference vulnerability in `(*backend).CreateInstanceFromBackup`. An authenticated user with permission to create instances can remotely trigger a crash of the Incus daemon by uploading a crafted backup tarball, causing denial of service to all projects on that cluster member.

Incus versions 6.21.0 and below allow a user with the ability to launch a container with a custom image (e.g., a member of the 'incus' group) to use directory traversal or symbolic links in the templating functionality to achieve host arbitrary file read and write, ultimately resulting in arbitrary command execution on the host. A fix is planned for versions 6.0.6 and 6.21.0.

Incus versions 6.20.0 and below allow a user with the ability to launch a container with a custom YAML configuration (e.g., a member of the 'incus' group) to create an environment variable containing newlines, which can be used to add additional configuration items in the container's lxc.conf. This can allow adding arbitrary lifecycle hooks, ultimately resulting in arbitrary command execution on the host. A fix is planned for versions 6.0.6 and 6.21.0.

Incus prior to version 7.3.0 has a vulnerability where a malicious image containing a `metadata.yaml` symlink pointing to an arbitrary host path allows an authenticated Incus user to read or overwrite any file on the host as root via the instance metadata API. The `exec-output` and `templates/` paths were patched earlier, but `metadata.yaml` was not included and remains exploitable.

Incus prior to version 7.3.0 allows an unprivileged, project-confined user (a non-admin TLS/RBAC identity with `can_create_images` and `can_create_instances`) to execute arbitrary code as root on the host. A crafted image ships `backup.yaml` as a symlink to a host file. When the root daemon writes the instance's backup file, it follows the symlink.

Incus prior to version 7.3.0 has a vulnerability where when copying an instance across projects, the project restriction check (`AllowInstanceCreation`) runs BEFORE the source instance's configuration is merged into the request. Dangerous configuration keys (including `security.privileged`, `raw.lxc`, `raw.apparmor`) from the source instance are merged AFTER the check passes, bypassing all project restrictions on the target project.

Incus prior to version 7.3.0 has a vulnerability where when migrating an instance to another cluster member, user-supplied configuration overrides (including security-critical keys like `security.privileged` and `raw.lxc`) are applied without any project restriction enforcement, allowing a restricted project user to escalate to a privileged container and escape to the host.

Incus prior to version 7.3.0 has a vulnerability where improper validation of user-provided `block.create_options` in storage volume configuration leads to argument injection in the constructed filesystem creation command line. This allows a project-scoped user to inject arbitrary arguments into the binary executed as root.

Incus prior to version 7.2.0 has an arbitrary file write vulnerability in the Incus client when a malicious image server returns a crafted `Incus-Image-Hash` header. This can lead to arbitrary command execution as root on the server.

Incus prior to version 7.1.0 has a vulnerability where improper validation of user-provided backup compression algorithm leads to argument injection in the constructed command line. This leads to an arbitrary file write on the host, possibly leading to arbitrary command execution.

Incus prior to version 7.1.0 has a path traversal vulnerability in the S3 protocol upload endpoint, allowing creation of arbitrary files on the host. This could lead to arbitrary command execution. Version 7.1.0 fixes the issue.

Incus prior to version 7.2.0 allows a specially crafted image or instance backup to read or create/write arbitrary files on the host, possibly leading to arbitrary command execution. Version 7.2.0 patches the issue.

Incus prior to version 7.2.0 ignores the `restricted.containers.lowlevel=block` setting for instance snapshots, allowing arbitrary command execution on the Incus server by abusing lowlevel hooks such as `raw.lxc` and `raw.qemu`. Version 7.2.0 patches the issue.

Incus prior to version 7.2.0 has a vulnerability in the `record-output` parameter of the `/instances/$name/exec` endpoint, where if `exec-output` is a symlink, files named `exec_UUID.stdout` and `exec_UUID.stderr` can be written to an arbitrary location, with the `.stdout` file containing arbitrary content. This can be abused for arbitrary command execution. Version 7.2.0 contains a patch.

Incus prior to version 7.2.0 allows a specially crafted image to read or create/write arbitrary files on the host, possibly leading to arbitrary command execution. Version 7.2.0 fixes the issue.

Incus before version 7.3.0 allows bypassing the `restricted.containers.privilege=isolated` restriction at the project level. A user can create a non-isolated container by omitting the `security.idmap.isolated` key, which defaults to `false`, allowing shared host uid/gid mapping. This weakens isolation between tenants and the host.

Incus is a system container and virtual machine manager. Prior to version 7.1.0, `(*backend).CreateCustomVolumeFromBackup` in `internal/server/storage/backend.go` contains an unguarded `*time.Time` dereference on the `ExpiresAt` field of every volume-snapshot entry in an imported custom-volume backup. An authenticated user with `can_create_storage_volumes` permission on any project can crash the `incusd` daemon by uploading a backup tarball whose `volume_snapshots[*].expires_at` field is absent. This is a sibling-field variant of GHSA-r7w7-mmxr-47r9 (CVE-2026-40197). Commit `985a1dedf9f3e7ba729c93b654905ed510de25c2` added `if s == nil` at the top of the loop body, but did not guard the adjacent `*snapshot.ExpiresAt` deref 19 lines later. Every other consumer of `Config.VolumeSnapshots[i].ExpiresAt` in this same file already gates the deref with a nil-check — the asymmetric guard is the bug. Version 7.1.0 contains an updated patch.

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.

Incus before version 7.0.0 sends a HEAD request to a user-supplied URL before validating project restrictions. An authenticated attacker can force the daemon to make blind HEAD requests to arbitrary destinations, leaking server metadata and enabling internal service probing.