CVE-2026-63295: LXD Authorization Bypass Vulnerability

CVE-2026-63295 Overview

CVE-2026-63295 is an authorization bypass vulnerability in LXD, the system container and virtual machine manager maintained by Canonical. The flaw allows an authenticated attacker to bypass project-level container isolation restrictions. When a project enforces restricted container privileges through restricted.containers.privilege=isolated, LXD fails to enforce this requirement if an instance configuration omits the security.idmap.isolated key. An attacker can create or update an instance without explicitly setting security.idmap.isolated, circumventing the target project's security constraints. The vulnerability is classified under [CWE-863: Incorrect Authorization].

Critical Impact
Authenticated attackers can bypass project isolation policies and deploy container instances that violate configured privilege restrictions, undermining multi-tenant boundaries.

Affected Products

Canonical LXD (system container and virtual machine manager)
LXD deployments enforcing restricted.containers.privilege=isolated project restrictions
Multi-tenant LXD environments relying on project-level isolation controls

Discovery Timeline

2026-08-12 - CVE-2026-63295 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-63295

Vulnerability Analysis

LXD uses projects to segment resources and enforce policy boundaries between tenants. Administrators can configure a project with restricted.containers.privilege=isolated to require that all instances in that project run with isolated user namespace mappings. This setting is enforced through the security.idmap.isolated instance key.

The vulnerability stems from an authorization check that only validates the isolation requirement when the key is explicitly present in the instance configuration. If an attacker submits an instance create or update request that omits security.idmap.isolated, LXD skips the enforcement path entirely. The instance is accepted without meeting the project-level isolation policy.

This pattern is a classic missing default-deny enforcement failure. The authorization layer trusts the absence of a field rather than treating unset security-relevant fields as non-compliant with restrictive project policies.

Root Cause

The root cause is incorrect authorization logic ([CWE-863]) in the project restriction enforcement code path. The check evaluates the value of security.idmap.isolated only when supplied, rather than defaulting to the project policy when the key is absent. Restrictive project constraints are silently bypassed for any instance configuration that omits the field.

Attack Vector

An attacker requires authenticated access to the LXD API with permissions to create or update instances within a restricted project. The attacker submits an instance configuration that deliberately omits security.idmap.isolated. LXD accepts the configuration and provisions an instance that does not honor the project's isolation requirement, weakening the security posture of the tenant boundary.

The vulnerability manifests in the project restriction validation logic. Refer to the GitHub Security Advisory GHSA-7vp9-3vmp-c5jm for technical details and patched versions.

Detection Methods for CVE-2026-63295

Indicators of Compromise

Instances within restricted projects where security.idmap.isolated is unset or missing from the effective configuration
LXD API audit log entries showing instance create or update calls that omit security.idmap.isolated in projects configured with restricted.containers.privilege=isolated
Container processes running with shared or non-isolated user namespace mappings in projects that should enforce isolation

Detection Strategies

Audit all LXD instances across restricted projects with lxc config show <instance> and verify that security.idmap.isolated is set to true where project policy requires isolation
Correlate LXD API access logs against project configuration to identify instance provisioning events that predate the patch and violate isolation policy
Compare effective UID/GID mappings across instances in the same project to identify inconsistent isolation enforcement

Monitoring Recommendations

Enable LXD API request logging and forward events to a centralized log platform for review
Monitor for instance create and update operations that omit security-relevant configuration keys within restricted projects
Alert on any modification to project restriction settings, especially changes to restricted.containers.privilege

How to Mitigate CVE-2026-63295

Immediate Actions Required

Upgrade LXD to the patched version identified in the GitHub Security Advisory GHSA-7vp9-3vmp-c5jm
Enumerate existing instances in restricted projects and verify each explicitly sets security.idmap.isolated=true where required
Restrict LXD API access to trusted operators until the patch is applied and configurations are validated

Patch Information

Canonical has published the security advisory at GHSA-7vp9-3vmp-c5jm. Apply the fixed LXD release referenced in the advisory. After patching, LXD enforces the project-level isolation requirement even when the instance configuration omits security.idmap.isolated.

Workarounds

Explicitly set security.idmap.isolated=true on every instance in projects requiring isolation, removing reliance on inherited project defaults
Reduce the privileges of LXD API clients so that only trusted administrators can create or update instances in restricted projects
Apply role-based access control policies to limit which users can modify instance configurations in multi-tenant deployments

bash

# Explicitly enforce isolated idmap on an existing instance
lxc config set <instance-name> security.idmap.isolated=true

# Verify the setting is applied
lxc config get <instance-name> security.idmap.isolated

# Review project restriction configuration
lxc project show <project-name>