CVE-2026-41685

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.