Description

Incus is a system container and virtual machine manager. Prior to version 7.3.0, project-level enforcement of `restricted.containers.privilege=isolated` can be trivially bypassed, allowing a user to create a non-isolated (shared host idmap) container in a project that is configured to forbid them. The restriction only rejects an explicitly set `security.idmap.isolated=false` (or empty) and fails to enforce anything when the key is omitted entirely. Because an unset `security.idmap.isolated` defaults to `false` (non-isolation), a user simply leaves the key out and obtains exactly the container state the restriction is meant to forbid. This defeats the tenant-isolation guarantee the restriction exists to provide. Containers in the project share the host uid/gid map instead of receiving unique, non-overlapping ranges, weakening the isolation boundary between co-tenant containers and the host. Version 7.3.0 patches the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-21T15:16:45.867Z",
  "pubdate": "2026-08-21T15:16:45.867Z",
  "executiveSummary": "An authorization bypass vulnerability exists in Incus prior to version 7.3.0, specifically affecting project-level configuration enforcement of the restricted.containers.privilege=isolated constraint. This security flaw allows authenticated users to circumvent tenant-isolation guarantees by omitting configuration parameters during container creation.\nThe vulnerability impacts Incus system container and virtual machine manager deployments utilizing project restrictions to enforce isolated user namespace mappings. The primary risk implication is a degradation of the multi-tenant isolation boundary, enabling co-tenant containers and the underlying host to share identical uid/gid maps.\nAn attacker with standard user capabilities within a restricted project can exploit this flaw. No complex privilege escalation or network exposure is required beyond standard API or command-line interaction with the Incus daemon. Exploitation relies entirely on omitting the security.idmap.isolated configuration key.\nSuccessful exploitation results in the creation of non-isolated containers with shared host idmaps inside projects explicitly configured to forbid them, compromising the security posture and tenant isolation architecture of the affected Incus environment.",
  "technicalDetails": "The root cause of the vulnerability resides in the validation logic for project-level restrictions within Incus prior to version 7.3.0. When the restriction restricted.containers.privilege=isolated is enforced on a project, the authorization subsystem specifically checks for explicitly supplied configuration keys to determine compliance.\nSpecifically, the validation mechanism only triggers a rejection when an explicitly set security.idmap.isolated=false parameter or an empty value is provided in the container creation request. The vulnerability occurs because the validation engine fails to enforce the restriction when the security.idmap.isolated key is omitted entirely from the payload.\nBecause the default state for an unset security.idmap.isolated configuration key evaluates to false, representing non-isolation, omitting the key causes the Incus daemon to instantiate a container utilizing a shared host uid/gid map instead of assigning unique, non-overlapping ranges.\nThe attack flow proceeds as follows: 1) An authenticated user targets a restricted Incus project where non-isolated containers are explicitly forbidden. 2) The user issues a container creation request via the Incus API or client CLI. 3) Rather than explicitly setting security.idmap.isolated to false (which would be blocked by the project policy), the user simply omits the security.idmap.isolated key entirely. 4) The authorization engine evaluates the omission as compliant due to flawed input validation logic, defaulting the internal state to non-isolated. 5) The Incus daemon provisions the container with a shared host idmap, directly violating project-level security policies.\nThe vulnerable component is the project restriction enforcement logic within the Incus container management daemon. Affected versions comprise all releases prior to version 7.3.0.\nAuthentication is required to interact with the Incus API and initiate container creation within a project. Standard user privileges within the target project are sufficient to execute the attack. Network exposure depends on the exposure of the Incus Unix socket or REST API endpoint.\nPost-exploitation impact includes the weakening of security boundaries between co-tenant containers and the host system, potentially facilitating container escape scenarios, unauthorized resource access, or privilege escalation primitives via shared user namespace mappings."
}