CVE-2026-62941 in Incus
Summary
by MITRE • 08/21/2026
Incus is a system container and virtual machine manager. Prior to version 7.3.0, 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. Version 7.3.0 patches the issue.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
Incus is a system container and virtual machine manager that provides infrastructure-as-code capabilities for managing Linux containers and VMs with features such as snapshots, live migration, and fine-grained access control through projects. Projects in Incus serve as logical partitions to isolate resources and enforce security boundaries between different tenants or operational units within the same host environment. The integrity of these project-based restrictions is critical for multi-tenant deployments where strict separation of privileges must be maintained to prevent lateral movement or privilege escalation across organizational boundaries.
The vulnerability identified prior to version 7.3.0 stems from a flawed sequence in the instance copying logic, specifically when an administrator attempts to duplicate an existing container or virtual machine into a different project. During this operation, Incus performs a security check known as AllowInstanceCreation to verify whether the target user has permission to create new instances within the destination project. This authorization step was executed before the system merged the configuration details from the source instance into the request payload intended for the newly created instance in the target project. Consequently, if the source instance contained dangerous or privileged configuration keys such as security.privileged, raw.lxc, or raw.apparmor, these settings were not evaluated during the initial permission check because they had not yet been applied to the new object's state at that moment.
This timing discrepancy allows an attacker with limited privileges in a restricted project to copy an instance from another project where those privileged configurations are permitted. Even if the user lacks explicit permissions to set security.privileged or manipulate raw.lxc directives directly, the act of copying bypasses these checks because the validation occurs against an empty or default configuration state rather than the actual inherited settings. Once the operation completes and the source configuration is merged into the new instance in the target project, the resulting container inherits elevated privileges such as root access within the host namespace via security.privileged, unrestricted command execution through raw.lxc shell escapes, or kernel-level code injection capabilities provided by raw.apparmor profiles that disable mandatory access controls. This effectively circumvents all intended isolation boundaries between projects, granting unauthorized users full control over the underlying system resources associated with their newly created instance.
From a classification perspective, this flaw represents CWE-20 Improper Input Validation as the system fails to validate input data against security policies at the correct stage of processing. It also aligns with ATT&CK technique T1548 Abuse Elevation Control Mechanism since it exploits improper enforcement of access control mechanisms to gain higher privileges than authorized. In multi-cloud or managed hosting environments, this vulnerability could lead to complete host compromise if an attacker leverages the privileged container to escape confinement and interact directly with the kernel or other running services on the physical server.
To mitigate this risk, organizations must immediately upgrade Incus to version 7.3.0 or later where the logic has been corrected to ensure that configuration merging occurs prior to permission validation. Until an upgrade is feasible, administrators should restrict access to instance copying operations and audit existing instances for dangerous configurations like security.privileged set to true or raw.lxc directives containing shell commands. Implementing strict role-based access control policies that limit who can initiate cross-project copy operations further reduces the attack surface by ensuring only trusted personnel with verified intent perform such high-risk administrative tasks. Regular penetration testing focused on container escape vectors and privilege escalation paths should also be conducted to detect any residual misconfigurations or unpatched instances in production environments.