Incus vulnerabilities

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 before 6.0.7, 6.1.0 before 7.0.2, and 7.1.0 before 7.5.0 contains an arbitrary file write vulnerability that allows malicious migration sources to write host files by planting symlinks in transferred volumes. Attackers can craft rsync or btrfs receive streams with a symlink such as rootfs pointing to the host root, writing files as root for full host compromise.

Incus 7.0.0 before 7.0.2 and 7.1.0 before 7.5.0 contains a path traversal vulnerability that allows clients able to create instances to write files on the host. The flaw stems from unvalidated dependent custom volume names in instance backup index.yaml files. Attackers can import a crafted instance backup with ../ sequences in dependent volume names to create root-owned directories with controlled content, leading to full host compromise.

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 contains an arbitrary file write vulnerability in sftpRecursivePullFile that allows a malicious incus-agent to escape the target directory during incus file pull -r. Attackers with root in a virtual machine can return duplicate entries reported first as symlinks then as files or directories, writing attacker-controlled files such as /etc/shadow on the operator's host.

Incus 7.0.1 before 7.0.2 and 7.2.0 before 7.5.0 contains an authorization bypass vulnerability that allows project-restricted clients to copy volumes by omitting source.type. Attackers can send crafted POST requests to the custom volumes endpoint with a chosen source.project to copy and read other projects' volumes, snapshots, and configuration.

Incus 7.0.0 before 7.0.2 and 7.1.0 before 7.5.0 contains a signature verification flaw in its built-in S3 server that allows presigned URL holders to inject unsigned x-amz-* headers. Attackers can add an unsigned X-Amz-Copy-Source header to a presigned upload URL to copy other bucket objects onto the granted key, disclosing their contents and ETags.

Incus contains a missing authorization vulnerability in GET /1.0/operations/{uuid} that lets project-restricted clients read operations in other projects. Attackers holding a restricted certificate and a known operation UUID can retrieve command lines, environment secrets, websocket secrets, and trust enrolment tokens.

Incus from 7.3.0 before 7.5.0 contains a project restriction bypass that allows restricted project users to set block.create_options through volume update, copy, and move operations. Attackers can set the option on a custom volume and trigger a copy or move onto a formatting pool to inject arguments into mkfs executed as root.

Incus 6.0.3 before 6.0.7, 6.6.0 before 7.0.2, and 7.1.0 before 7.5.0 contains an improper authorization vulnerability that allows restricted TLS clients to read storage bucket keys in the default project. Attackers can query the bucket keys endpoints to obtain S3 access and secret keys, then read, modify or delete objects in those buckets.

A restriction bypass vulnerability in Incus allows restricted project users to use pull mode migration via clustered refresh requests. An attacker with instance creation rights can send a refresh migration request for an existing instance, causing the server to open outbound TLS websocket connections and probe reachable services.

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 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 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.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 is a system container and virtual machine manager. Prior to version 7.0.0, uploads of large amounts of data by authenticated users can run the Incus server out of disk space, potentially taking down the host system. The impact is limited for users of storage.images_volume and storage.backups_volume as large uploads are stored on those volumes rather than directly on the host filesystem (default behavior on IncusOS).

Incus prior to version 7.0.0 trusts the inline backup/index.yaml config when present and only falls back to parsing the legacy backup/container/backup.yaml if result.Config is nil. A crafted archive can carry a valid inline config that passes preflight while also carrying a malformed legacy backup.yaml without a container section, leading to nil dereference and daemon crash. The issue occurs in the restore and import flow.

Prior to version 7.0.0, Incus unpacked user-provided image and backup tarballs and parsed YAML files without any size restrictions. An authenticated user could supply a crafted image or backup tarball that, when parsed by Incus, loaded a very large YAML document into memory, potentially causing the entire server to run out of memory. This issue has been patched in version 7.0.0.

Incus prior to version 7.0.0 has missing error handling that could allow an authenticated user to cause a daemon crash through the import of a truncated storage bucket backup file. The issue has been patched in version 7.0.0.

In Incus before version 7.0.0, missing validation in the storage volume import logic allows an authenticated user with access to the storage volume feature to crash the Incus daemon. The backup restore subsystem contains an out-of-bounds panic due to an incorrect bounds check len(slice) >= i-1 when indexing snapshot metadata arrays, also present in the migration path. An attacker can submit a backup archive with physical snapshot directories and a tampered index.yaml with an empty or truncated metadata array, causing the daemon to crash and resulting in denial of service. The issue is fixed in version 7.0.0.

In Incus before 7.0.0, broken TLS validation logic in OVN database connections means the custom verifier does not anchor trust in the configured CA but instead uses peer-supplied certificates. This allows an active attacker to impersonate the OVN endpoint with a rogue certificate chain.

In Incus before version 7.0.0, missing validation in the storage volume import logic allows an authenticated user with access to the storage volume feature to crash the Incus daemon. The custom volume backup import subsystem contains a nil-pointer dereference during import: the snapshot import loop iterates over srcBackup.Config.VolumeSnapshots and assumes each element is initialized, then dereferences fields such as Name, Config, Description, CreatedAt, and ExpiresAt without validation. Because the YAML unmarshaler accepts explicit null array elements from an attacker-controlled index.yaml and converts them into nil pointers, an attacker can supply a backup archive with a null entry in the volume_snapshots array, causing a nil-pointer dereference and terminating the daemon. The issue is fixed in version 7.0.0.

In Incus before version 7.0.0, missing validation in the storage bucket import logic allows an authenticated user with access to the storage bucket feature to crash the Incus daemon. The daemon processes the index.yaml file from an imported archive and accesses members of the parsed backup configuration without first verifying that the configuration object was initialized. A malicious or malformed index.yaml that omits the config block causes a nil-pointer dereference during bucket import and terminates the daemon, resulting in denial of service. The issue is fixed in version 7.0.0.

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.