CVE-2026-62313: Incus Container Auth Bypass Vulnerability

CVE-2026-62313 Overview

CVE-2026-62313 is an authorization flaw in Incus, a system container and virtual machine manager. Versions prior to 7.3.0 fail to enforce the restricted.containers.privilege=isolated project restriction when the security.idmap.isolated key is omitted from a container configuration. A user with project-level access can create a non-isolated container in a project explicitly configured to forbid this state, breaking tenant-isolation guarantees. The affected containers share the host uid/gid map rather than receiving unique, non-overlapping ranges, weakening the boundary between co-tenant containers and the host. This weakness is tracked as CWE-863: Incorrect Authorization.

Critical Impact
Authenticated tenants can bypass project-level isolation policy and create shared-idmap containers, degrading multi-tenant isolation between containers and the host.

Affected Products

Incus system container and virtual machine manager
All versions prior to 7.3.0
Deployments using project-level restricted.containers.privilege=isolated enforcement

Discovery Timeline

2026-08-21 - CVE-2026-62313 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-62313

Vulnerability Analysis

Incus supports multi-tenant deployments through projects, where restricted.containers.privilege=isolated requires each container to receive a unique, non-overlapping uid/gid mapping. The enforcement logic inspects the security.idmap.isolated configuration key and rejects values of false or empty strings. The check does not handle the case where the key is entirely absent from the container definition.

Because the effective default for an unset security.idmap.isolated is false, a user who omits the key receives a shared host-idmap container. This is exactly the state the project restriction exists to forbid. The bypass requires only standard project-level create permissions and does not require any additional privilege or exploitation primitive.

The resulting container shares the host uid/gid ranges with other non-isolated containers in the project. This eliminates the kernel-level user namespace separation that isolated idmaps provide, increasing the blast radius of any container escape or in-container compromise.

Root Cause

The root cause is an allow-list style check applied to a value that has a permissive default. The restriction rejects explicitly disabled isolation but treats a missing key as compliant. The correct behavior is to require an explicit security.idmap.isolated=true when the project restriction is set, or to inject that value at admission time.

Attack Vector

An authenticated user with permission to create containers inside a restricted project submits a container definition that omits security.idmap.isolated entirely. Incus admits the container without applying isolated idmap ranges, giving the user a shared-idmap container in violation of project policy. See the GitHub Security Advisory GHSA-53cg-qvg7-m8vg for the vendor's technical description.

// Vulnerable configuration pattern (conceptual)
// Project policy: restricted.containers.privilege=isolated
// Attacker container definition omits the key entirely:
//   security.idmap.isolated  <-- not set
// Result: container runs with shared host idmap, bypassing policy

Detection Methods for CVE-2026-62313

Indicators of Compromise

Containers inside projects with restricted.containers.privilege=isolated that lack an explicit security.idmap.isolated=true setting.
Multiple containers within a single restricted project sharing overlapping uid/gid ranges on the host.
Audit-log entries showing container creation requests that omit the security.idmap.isolated key.

Detection Strategies

Enumerate containers per project using incus config show and flag any container in a restricted project whose expanded config does not resolve security.idmap.isolated to true.
Compare on-host uid/gid ranges across containers in the same project to identify shared-idmap instances that violate tenant policy.
Review Incus API and CLI audit logs for container create operations that succeeded in restricted projects without setting the idmap key.

Monitoring Recommendations

Ingest Incus daemon logs and API audit events into a centralized data lake for continuous policy validation.
Alert on any newly created container in a restricted project that does not have isolated idmap ranges applied at runtime.
Track the Incus daemon version across managed hosts and alert when versions below 7.3.0 remain in production.

How to Mitigate CVE-2026-62313

Immediate Actions Required

Upgrade Incus to version 7.3.0 or later on all hosts running multi-tenant projects.
Audit every project with restricted.containers.privilege=isolated for pre-existing non-isolated containers and remediate them.
Restrict container creation permissions in shared projects to trusted operators until upgrades complete.

Patch Information

Incus version 7.3.0 patches the issue by enforcing the restriction when security.idmap.isolated is omitted. Review the GitHub Security Advisory GHSA-53cg-qvg7-m8vg for full upgrade guidance and backport availability.

Workarounds

Explicitly set security.idmap.isolated=true on every container profile applied within restricted projects.
Apply a project default profile that injects security.idmap.isolated=true so omission by users has no effect.
Temporarily remove container-create permissions from untrusted tenants in affected projects until the patch is deployed.

bash

# Configuration example: enforce isolated idmap via a project default profile
incus profile set default security.idmap.isolated=true

# Verify each container in a restricted project resolves the key to true
incus config get <container-name> security.idmap.isolated