CVE-2026-63296: LXD Auth Bypass Vulnerability

CVE-2026-63296 Overview

CVE-2026-63296 is an authorization bypass vulnerability in LXD, the Canonical container and virtual machine manager. The flaw allows an authenticated attacker to bypass target project restrictions during instance migration. LXD accepts configuration overrides when migrating an instance to a target project but fails to validate the new configuration against that project's enforced restrictions. Attackers can move instances with high-privilege configurations into restricted projects, circumventing multi-tenant security controls. The vulnerability is classified under CWE-863: Incorrect Authorization.

Critical Impact
Authenticated users with migration privileges can bypass project restrictions, escalate instance privileges, and undermine tenant isolation guarantees in shared LXD environments.

Affected Products

Canonical LXD (see the GitHub Security Advisory GHSA-gcr9-5q6r-w625 for affected version ranges)
LXD deployments configured with multi-project restrictions
Shared or multi-tenant LXD clusters relying on project-level policy enforcement

Discovery Timeline

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

Technical Details for CVE-2026-63296

Vulnerability Analysis

LXD organizes workloads into projects, each of which can enforce restrictions on what instance configurations are permitted. These restrictions prevent tenants from enabling privileged containers, host device passthrough, unrestricted networking, or other high-privilege options in sensitive projects.

The migration workflow allows callers to supply configuration overrides that apply to the instance in its new project. The vulnerability stems from LXD applying these overrides without re-evaluating them against the destination project's restricted.* policies. An authenticated user with rights to migrate an instance can therefore land a workload in a restricted project while retaining or introducing configurations that the destination policy would otherwise reject.

The result is a policy enforcement gap between direct instance creation and instance migration. Direct creation in a restricted project is validated; migration is not.

Root Cause

The root cause is missing authorization enforcement on the migration code path. LXD validates configuration against project restrictions during instance creation and updates but omits the equivalent check when a migration request supplies overrides for the target project. This is a classic [CWE-863] incorrect authorization pattern where a secondary code path fails to apply the security policy enforced elsewhere.

Attack Vector

Exploitation requires an authenticated LXD user with permission to migrate instances between projects. The attacker initiates a project-to-project migration and includes configuration overrides that would normally be blocked by the destination project's restrictions, such as security.privileged=true, host device entries, or unrestricted network attachments. LXD applies the overrides and completes the migration, resulting in an instance running in the restricted project with disallowed privileges.

Refer to the Canonical LXD security advisory for technical details and affected version ranges.

Detection Methods for CVE-2026-63296

Indicators of Compromise

Instances present in restricted projects with configuration keys that violate that project's restricted.* policy, such as security.privileged=true or security.nesting=true.
LXD API audit records showing successful POST /1.0/instances/{name}?target=... or migration operations that include configuration overrides.
Recently migrated instances whose runtime configuration diverges from the destination project's baseline template.

Detection Strategies

Perform a configuration audit across all projects using lxc config show and compare instance settings against each project's lxc project show restrictions.
Enable and review LXD audit logging for migration events, focusing on operations that specify source and target projects with override payloads.
Alert on any instance configuration change in a restricted project where the modification originated from a migration operation rather than an authorized update.

Monitoring Recommendations

Forward LXD daemon logs and API operation records to a centralized logging pipeline for retention and correlation.
Monitor for privilege-relevant configuration keys appearing in projects that explicitly restrict them.
Track authenticated LXD identities that perform cross-project migrations and review their activity for anomalies.

How to Mitigate CVE-2026-63296

Immediate Actions Required

Upgrade LXD to the patched release identified in the Canonical security advisory GHSA-gcr9-5q6r-w625.
Inventory all instances in restricted projects and revert any configurations that violate project policy.
Restrict LXD migration privileges to trusted operators pending remediation.

Patch Information

Canonical has published fix information in the LXD Security Advisory GHSA-gcr9-5q6r-w625. Administrators should apply the vendor-supplied update on all LXD daemons in the cluster and restart the service to ensure the patched migration validation logic is loaded.

Workarounds

Temporarily revoke the can_edit and migration-related permissions from non-administrative users on restricted projects until patches are deployed.
Disable project-to-project migration workflows in automation and CI pipelines that could carry attacker-controlled overrides.
Manually re-validate instance configurations against destination project restrictions before approving any migration request.

bash

# Configuration example: audit restricted projects and remove disallowed privileged instances
for project in $(lxc project list -f csv | cut -d, -f1); do
  echo "=== Project: $project ==="
  lxc project show "$project" | grep -E '^\s+restricted'
  lxc list --project "$project" -c ns -f csv | while IFS=, read -r name status; do
    priv=$(lxc config get "$name" security.privileged --project "$project" 2>/dev/null)
    nest=$(lxc config get "$name" security.nesting --project "$project" 2>/dev/null)
    [ "$priv" = "true" ] && echo "VIOLATION: $name has security.privileged=true"
    [ "$nest" = "true" ] && echo "REVIEW: $name has security.nesting=true"
  done
done