CVE-2026-63299: LXD Authorization Bypass Vulnerability

CVE-2026-63299 Overview

CVE-2026-63299 is an authorization bypass vulnerability in LXD, the system container and virtual machine manager developed by Canonical. Authenticated users can bypass project-level disk and volume limits through two flawed code paths in volume operations. The storagePoolVolumeTypePostMove function omits the limits.AllowVolumeCreation check when moving a volume across projects. Volume snapshot restore operations also skip the AllowVolumeUpdate check when the configuration is nil (Config == nil). Attackers can allocate storage resources that exceed administrative project limits, leading to resource exhaustion and impact on other tenants.

Critical Impact
Authenticated users can exceed administrative disk and volume quotas, exhausting shared storage and breaking project isolation boundaries in multi-tenant LXD deployments.

Affected Products

Canonical LXD (system container and VM manager)
LXD deployments using project-level limits.AllowVolumeCreation and AllowVolumeUpdate controls
Multi-tenant environments relying on LXD project isolation

Discovery Timeline

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

Technical Details for CVE-2026-63299

Vulnerability Analysis

The vulnerability is classified as an authorization bypass mapped to [CWE-770] (Allocation of Resources Without Limits or Throttling). LXD projects enforce quota controls through limit checks executed before storage-modifying operations. Two code paths fail to invoke these checks, allowing authenticated users to exceed their allocated storage.

The first flawed path exists in storagePoolVolumeTypePostMove, which handles moving volumes between projects. The function omits the limits.AllowVolumeCreation verification before completing the move. An attacker with credentials in a source project can relocate volumes into a destination project without enforcement of that project's creation quota.

The second flaw occurs during volume snapshot restore operations. When the volume Config is nil, the code path skips the AllowVolumeUpdate check. This allows snapshot restores to bypass update limits and modify storage state beyond the configured bounds.

Root Cause

The root cause is missing authorization checks in two volume-lifecycle code paths. LXD's project-scoped resource limits depend on centralized limit-check helpers, but the affected functions do not invoke them in every reachable branch. The nil-configuration branch in snapshot restore illustrates a common defect pattern where absent input is treated as a fast path rather than as a case requiring the same policy enforcement.

Attack Vector

Exploitation requires an authenticated LXD API user with permission to perform volume moves or snapshot restores in a project. The attacker triggers a cross-project volume move through the storage pool volume API to bypass AllowVolumeCreation. Alternatively, the attacker invokes a snapshot restore with a nil configuration to bypass AllowVolumeUpdate. Both actions cause storage allocation to exceed administrative limits without any privilege escalation beyond the initial project access.

No public proof-of-concept exploit is available at the time of publication. Refer to the GitHub Security Advisory GHSA-5h78-p252-989h for the vendor's technical description.

Detection Methods for CVE-2026-63299

Indicators of Compromise

Storage pool utilization exceeding configured project quotas without a corresponding administrative change
Volume move operations in LXD audit logs targeting destination projects where the acting user lacks creation quota
Snapshot restore API calls that complete despite the destination project being at or above its AllowVolumeUpdate limit

Detection Strategies

Enable LXD API access logging and forward events to a centralized analytics platform for correlation of volume move and snapshot restore operations against project quotas
Compare actual per-project storage consumption against the configured limits.disk and volume-count limits on a scheduled basis and alert on deviations
Review API traffic for POST requests to storage volume move endpoints originating from non-administrative accounts

Monitoring Recommendations

Instrument LXD host storage backends (ZFS, LVM, Ceph, Btrfs) with utilization alerts sized below the sum of project quotas to detect over-allocation
Collect LXD daemon logs and correlate authentication identity with volume operation types to identify unusual patterns
Track counts of storagePoolVolumeTypePostMove and snapshot restore invocations per user and flag statistical outliers

How to Mitigate CVE-2026-63299

Immediate Actions Required

Upgrade LXD to the fixed release identified in the Canonical LXD Security Advisory GHSA-5h78-p252-989h
Audit existing projects for storage consumption that exceeds configured limits and reconcile any overages
Restrict LXD API access to trusted administrators until patching is complete in multi-tenant deployments

Patch Information

Canonical published the fix through the LXD security advisory GHSA-5h78-p252-989h. The patch adds the missing limits.AllowVolumeCreation check to storagePoolVolumeTypePostMove and enforces AllowVolumeUpdate in the snapshot restore path when the volume configuration is nil. Consult the vendor advisory for the exact fixed versions applicable to your distribution channel.

Workarounds

Revoke or reduce project-scoped permissions that allow volume moves and snapshot restores for non-administrative users
Enforce storage-backend quotas at the underlying filesystem or block storage layer (for example, ZFS dataset quotas) as a defense-in-depth control independent of LXD project limits
Isolate untrusted tenants on separate LXD hosts or storage pools until patching completes

bash

# Example: apply a ZFS dataset quota as a backend-level control
zfs set quota=100G tank/lxd/project-tenant-a

# Example: review current LXD project limits
lxc project show tenant-a