CVE-2026-62940: Incus Privilege Escalation Vulnerability

CVE-2026-62940 Overview

CVE-2026-62940 is a missing authorization vulnerability [CWE-862] in Incus, an open-source system container and virtual machine manager. During instance migration between cluster members, Incus applies user-supplied configuration overrides without enforcing project-level restrictions. A restricted project user can inject security-sensitive keys such as security.privileged and raw.lxc to escalate an unprivileged container to a privileged one and escape to the host. The flaw affects all releases prior to 7.3.0 and is fixed in version 7.3.0.

Critical Impact
Authenticated low-privilege users in restricted Incus projects can escape container isolation, gain root on the underlying cluster host, and pivot across the cluster.

Affected Products

Incus system container and virtual machine manager
Incus versions prior to 7.3.0
Multi-tenant Incus clusters using project-based restrictions

Discovery Timeline

2026-08-21 - CVE-2026-62940 published to the National Vulnerability Database (NVD)
2026-08-21 - Last updated in NVD database

Technical Details for CVE-2026-62940

Vulnerability Analysis

Incus supports project-scoped access control, allowing administrators to grant users limited permissions inside a tenant boundary. Restricted projects normally block security-sensitive configuration keys, including security.privileged, security.nesting, and raw.lxc. These keys can grant a container root-equivalent access to the host kernel.

The migration workflow between cluster members accepts a configuration override payload from the requesting user. Prior to 7.3.0, the migration handler applied these overrides directly to the target instance without re-evaluating the project's restriction policy. A restricted user with permission to migrate their own instance can therefore inject keys that the project would otherwise reject.

Once the container is scheduled on the destination node with security.privileged=true or a crafted raw.lxc block, the container runs with UID 0 mapped to host UID 0. From that position, an attacker can access host devices, mount the host filesystem, and execute arbitrary commands on the cluster member.

Root Cause

The defect is a missing authorization check in the cluster migration code path. Project restriction validation is enforced when instances are created or updated through the standard API, but the migration override handler bypassed the same policy engine. The result is a broken access control condition where privilege boundaries are enforced inconsistently across code paths.

Attack Vector

Exploitation requires an authenticated Incus user with rights to trigger a migration inside a restricted project. The attacker issues a migration request that includes a configuration override map containing forbidden keys. Incus applies the override on the destination member, launches the privileged container, and the attacker breaks out to the host through standard privileged-container techniques such as mounting /dev/sda or abusing raw.lxc mount entries. Refer to the GitHub Security Advisory GHSA-qw5c-v953-38gw for advisory details.

Detection Methods for CVE-2026-62940

Indicators of Compromise

Migration API requests containing security.privileged, security.nesting, or raw.lxc in the configuration override payload originating from restricted project users.
Instances running with security.privileged=true inside projects that declare restricted=true.
Unexpected lxc.mount.entry or lxc.cgroup directives added through raw.lxc after a cluster migration event.
Host-level processes spawned by container init with UID 0 mapping to host UID 0 following a recent migration.

Detection Strategies

Audit the Incus server log for POST /1.0/instances/<name>?target=<member> requests and correlate submitted configuration keys against the project restriction policy.
Compare pre-migration and post-migration instance configurations to identify keys that violate project restrictions.
Alert on any restricted project instance whose effective configuration contains privileged security keys.

Monitoring Recommendations

Forward Incus daemon logs and audit events to a centralized logging or SIEM platform for retention and correlation.
Baseline expected migration activity per project and alert on migrations that mutate security-relevant keys.
Monitor host processes on cluster members for container escapes such as unexpected mount, nsenter, or kernel module loads originating from container cgroups.

How to Mitigate CVE-2026-62940

Immediate Actions Required

Upgrade all Incus cluster members to version 7.3.0 or later, which enforces project restrictions during migration.
Inventory existing instances in restricted projects and remove any that contain security.privileged=true, security.nesting=true, or non-empty raw.lxc values that were not administrator-approved.
Rotate credentials and API tokens for any restricted-project users who could have exercised migration privileges before patching.

Patch Information

Upstream Incus release 7.3.0 fixes the missing authorization check by re-evaluating project restrictions against user-supplied migration overrides. See the GitHub Security Advisory GHSA-qw5c-v953-38gw for the fix commit and release notes. Distributions repackaging Incus should ship the patched release before re-enabling multi-tenant migration.

Workarounds

Temporarily revoke migration permissions from all restricted project users until the cluster is upgraded to 7.3.0.
Disable cross-member migration in multi-tenant clusters by consolidating restricted-project workloads onto a single member.
Enforce administrator review of any instance configuration changes that touch security.* or raw.lxc keys.

bash

# Configuration example: remove migration rights from a restricted project group
incus auth group permission remove <group> project <restricted-project> can_edit
incus auth group permission remove <group> project <restricted-project> operator

# Verify the project enforces restrictions
incus project show <restricted-project> | grep -E 'restricted|security'