CVE-2026-63300: LXD Auth Bypass Vulnerability

CVE-2026-63300 Overview

CVE-2026-63300 is an improper validation vulnerability in the instancePostMigration function within lxd/instance_post.go of LXD. The flaw allows an authenticated attacker with can_create_instances permissions on a restricted project to bypass project-level security restrictions. When LXD migrates an instance between projects, it fails to validate the instance's configuration against the target project's enforced restrictions. Attackers create a disallowed or high-privilege instance in an unrestricted project and then move it into the restricted project, evading controls such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access.

Critical Impact
Authenticated users can bypass LXD project isolation to deploy privileged containers, restricted device configurations, or unauthorized network access in projects hardened by administrators.

Affected Products

Canonical LXD (container and virtual machine manager)
LXD deployments using project-level restrictions for multi-tenant isolation
LXD instances managed through the instance_post migration API

Discovery Timeline

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

Technical Details for CVE-2026-63300

Vulnerability Analysis

LXD supports multi-tenant isolation through projects, allowing administrators to apply per-project restrictions that limit what instance configurations are permitted. Restrictions such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access prevent tenants from creating privileged containers or attaching sensitive devices and networks. The instancePostMigration function handles instance moves between projects but omits validation of the instance configuration against the destination project's restriction policy. This missing authorization check maps to [CWE-862: Missing Authorization].

The result is a project boundary bypass. An attacker with instance creation rights in any unrestricted project can craft an instance that would be rejected by policy in the target project, then migrate it in. The migration path accepts the existing configuration without re-evaluating whether it complies with the target project's rules.

Root Cause

The root cause is missing enforcement of project-level restriction policy during instance migration. LXD validates configuration against project restrictions at instance creation time but not when an instance transitions between projects. The instancePostMigration handler treats the migration as a metadata operation rather than a policy-relevant state change.

Attack Vector

An authenticated attacker with can_create_instances in an unrestricted source project creates an instance configured with disallowed settings, such as low-level container options, privileged devices, or unrestricted network access. The attacker then invokes the instance move API to transfer the instance into the restricted target project. LXD accepts the migration and the instance runs in the restricted project with configuration that policy should have blocked. See the GitHub Security Advisory GHSA-5g5r-wh97-qcq2 for full technical details.

Detection Methods for CVE-2026-63300

Indicators of Compromise

Instances in restricted projects that carry configuration keys or devices prohibited by the project's restricted.* policy.
Audit log entries showing POST /1.0/instances/{name} migration calls targeting projects with active restrictions.
Instances whose creation history shows an origin in an unrestricted project followed by a project move.
Presence of privileged containers, host device passthrough, or unrestricted network attachments in tenants that should not have them.

Detection Strategies

Compare running instance configurations in each project against the project's declared restricted.* policy and flag discrepancies.
Correlate LXD API audit logs to identify migration events across project boundaries, especially from unrestricted to restricted projects.
Alert on any use of the instance move operation performed by non-administrative accounts.

Monitoring Recommendations

Enable and centrally forward LXD audit logs to a SIEM for continuous review of instance lifecycle and migration events.
Track authentication events for identities holding can_create_instances across multiple projects.
Baseline instance counts and configuration profiles per project and alert on unexpected changes following migration operations.

How to Mitigate CVE-2026-63300

Immediate Actions Required

Update LXD to a fixed release containing the patches from PR #18605 and PR #18651.
Review all instances residing in restricted projects and remove or reconfigure any that violate the project's restricted.* policy.
Restrict can_create_instances permissions to trusted users and limit cross-project migration rights.

Patch Information

Canonical addressed the vulnerability in upstream LXD through pull requests #18605 and #18651. The fix adds validation of the instance's configuration against the target project's restrictions inside instancePostMigration. Refer to GHSA-5g5r-wh97-qcq2 for affected and fixed version ranges.

Workarounds

Revoke instance migration privileges for non-administrative identities until the patch is applied.
Disable cross-project instance moves through role-based access control policies on the LXD API.
Enforce administrative approval for any instance transfer into projects that carry restricted.* settings.
Audit and remove stale or misconfigured instances that may have been migrated prior to patching.

bash

# Verify LXD version and list instances per project for policy review
lxc version
lxc project list
for p in $(lxc project list -f csv | cut -d, -f1); do
  echo "=== Project: $p ==="
  lxc project show "$p" | grep -E 'restricted'
  lxc list --project "$p" -c ns,type,config
done