Description

An authorization bypass vulnerability in LXD allows an authenticated user to bypass project-level disk and volume limits. Two related code paths fail to verify resource limits during volume operations: the storagePoolVolumeTypePostMove function omits the limits.AllowVolumeCreation check before moving a volume across projects, and volume snapshot restore operations skip the AllowVolumeUpdate check when the configuration is nil (Config == nil). An attacker can exploit these flaws to allocate storage resources that exceed the administrative limits configured for a project.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-12T20:17:47.830Z",
  "pubdate": "2026-08-12T20:17:47.830Z",
  "executiveSummary": "An authorization bypass vulnerability exists in the LXD container and virtual machine management daemon, specifically within project-level resource enforcement logic.\nThe vulnerability allows an authenticated user with access to a project to bypass administrative disk and volume limits.\nThe flaw manifests in two distinct code paths: the storagePoolVolumeTypePostMove function, which fails to invoke the limits.AllowVolumeCreation verification check during cross-project volume move operations, and volume snapshot restore routines, which omit the AllowVolumeUpdate validation check when the volume configuration is evaluated as nil.\nSuccessful exploitation enables malicious or unauthorized authenticated actors to provision storage resources that explicitly exceed quotas and constraints established by system administrators for specific projects.\nThis can lead to resource exhaustion, denial of service conditions through storage starvation, and violation of multi-tenant isolation boundaries within the host environment.\nRemediation requires applying the official vendor patches to address the missing validation checks in the affected storage management functions.",
  "technicalDetails": "The vulnerability is an authorization bypass flaw impacting resource quota enforcement within LXD storage management subsystems.\nThe root cause stems from omitted validation checks across two primary code paths responsible for handling storage volumes and snapshots.\nIn the first vulnerable code path, the storagePoolVolumeTypePostMove function processes the relocation of storage volumes between projects. During this operation, the codebase fails to call the critical limits.AllowVolumeCreation check, allowing a user to move volumes into a project without validating whether the resulting state violates the destination project's allocated disk and volume ceilings.\nIn the second vulnerable code path, volume snapshot restore operations fail to execute the limits.AllowVolumeUpdate check when the underlying configuration parameter evaluates to nil (Config == nil). This lack of validation allows snapshot restorations to bypass enforcement logic that would otherwise restrict storage expansion.\nAn attacker must be an authenticated user with sufficient project access to initiate volume move or snapshot restore commands.\nThe attack flow proceeds as follows: First, the authenticated attacker identifies or establishes a project with strict administrative storage limits. Second, the attacker interacts with the LXD API to either move an existing volume across projects via the deficient storagePoolVolumeTypePostMove logic or triggers a snapshot restore with a nil configuration state.\nBecause the validation functions limits.AllowVolumeCreation and limits.AllowVolumeUpdate are bypassed, the storage operation completes successfully regardless of quota constraints.\nPost-exploitation impact includes unauthorized storage allocation, potential host-level resource exhaustion, and degradation of performance or availability for other tenants sharing the same storage pool."
}