EUVD-2026-57418Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to LXD project with volume rights
-
DeliveryIssue cross-project volume move or nil-config snapshot restore
-
ExploitLimit check (AllowVolumeCreation/AllowVolumeUpdate) skipped
-
ExecutionAllocate storage beyond project quota
-
ImpactRepeat to exhaust shared storage pool
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an authenticated LXD user (CVSS PR:L) holding permissions to perform volume operations within a project that has configured disk/volume limits - specifically the ability to trigger a cross-project volume move (storagePoolVolumeTypePostMove) or to restore a volume snapshot where the volume configuration is nil (Config == nil). The bypass is only meaningful where project-level storage quotas are actually configured as a boundary (multi-tenant clusters); single-tenant or quota-less deployments gain little for an attacker. Limiting factors: authentication is mandatory, the actor must already have volume-management rights in a project, and impact is confined to storage over-allocation rather than host or data compromise. |
| Impact | The signals here conflict and should be reconciled before treating this as a top-tier crisis. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) claims full confidentiality, integrity, and availability compromise, but the description and the vendor's own 'Denial Of Service' tag point to a resource-limit bypass whose true impact is availability/quota exhaustion - not data disclosure or code integrity loss. The high C:H/I:H rating appears inflated for a quota-enforcement gap; verify with the vendor advisory before repeating the 9.9 figure. There is no EPSS value in the input, no KEV listing, and no evidence of a public POC, so real-world exploitation pressure is currently low. Realistic priority is moderate: it requires an already-authenticated project user and yields resource over-allocation rather than tenant takeover, so it matters most in shared/multi-tenant LXD clusters where storage isolation is a security boundary. |
| Exploit ScenarioDerived | A tenant with legitimate access to an LXD project that has a strict storage quota repeatedly moves volumes in from another project (or restores snapshots on volumes with nil config), each operation slipping past the AllowVolumeCreation/AllowVolumeUpdate check. Over successive operations the tenant allocates storage well beyond the project's limits.disk ceiling, exhausting the shared storage pool and degrading service for co-located tenants. No public POC is identified at time of analysis, and the low attack complexity (AC:L) means the steps are straightforward once project access is held. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Aug 12, 2026
Storage quota bypass in Canonical LXD (5.0.x before 5.0.8, 5.21.x before 5.21.6, and 6.0 before 6.10) lets an authenticated user exceed the disk and volume limits an administrator configured on a project. The flaw stems from two code paths - cross-project volume moves (storagePoolVolumeTypePostMove) and volume snapshot restores with a nil config - that skip the AllowVolumeCreation/AllowVolumeUpdate limit checks, enabling over-allocation of storage. Reported by Canonical with a patch available; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Earlier versions of this analysis (1)
Authorization bypass in LXD (Canonical's container and VM manager) enables authenticated users to silently exceed project-level disk and volume quotas enforced by administrators. Two discrete code paths skip mandatory limit checks: cross-project volume moves bypass limits.AllowVolumeCreation, and snapshot restores with a nil volume configuration bypass limits.AllowVolumeUpdate. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but in multi-tenant deployments where project quotas represent the primary isolation boundary, successful exploitation can exhaust host-level disk resources and cascade availability impact to other projects.
RemediationAI
Vendor-released patch: upgrade to LXD 5.0.8, 5.21.6, or 6.10 (whichever matches your branch) as the primary fix, per Canonical advisory GHSA-5h78-p252-989h (https://github.com/canonical/lxd/security/advisories/GHSA-5h78-p252-989h). Where immediate patching is not possible on a multi-tenant deployment, reduce exposure by restricting who holds project-member permissions that can move volumes or restore snapshots, and audit for volumes whose allocations exceed their project's limits.disk ceiling; note that tightening project RBAC will curtail legitimate self-service volume operations and is only a stopgap until the upgrade. Because the bypass depends on operations issued through authenticated LXD API access, limiting API exposure to trusted operators and monitoring storage usage against configured quotas are reasonable compensating controls with the trade-off of added operational friction.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
LXD is Canonical's system container and virtual-machine manager, which enforces multi-tenancy through 'projects' that can carry resource quotas including limits.disk and per-volume storage caps. This vulnerability is a CWE-770 (Allocation of Resources Without Limits or Throttling) issue: the enforcement helpers limits.AllowVolumeCreation and limits.AllowVolumeUpdate are the gatekeepers that reconcile a requested allocation against a project's configured ceiling. In the affected builds, storagePoolVolumeTypePostMove moves a volume between projects without invoking AllowVolumeCreation in the destination project, and the snapshot-restore path short-circuits AllowVolumeUpdate whenever the volume Config is nil, so neither operation reconciles the new footprint against the quota. The affected CPE is cpe:2.3:a:canonical:lxd, and the fix is tracked in GHSA-5h78-p252-989h (EUVD-2026-57418).
Know when Lxd gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Authenticated project user (PR:L) over the network API (AV:N/AC:L); impact is storage over-allocation, so A:H with minor integrity (I:L) and no confidentiality, and no scope change.
Primary rating from Vendor (canonical).
CVSS VectorVendor: canonical
Lifecycle Timeline
5DescriptionCVE.org
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 ViewAI
Canonical LXD versions 5.0.x through 5.21.x and 6.0 before 6.10 contain a critical storage quota bypass vulnerability (CVSS 9.9) that allows authenticated users to exceed disk and volume limits set by administrators, compromising resource isolation and operational control in multi-tenant containerized environments. This flaw directly undermines administrative policies and can enable resource exhaustion attacks or service disruption by privileged users or compromised accounts.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Cross-site request forgery in the LXD-UI component of Canonical LXD 5.0 before 5.0.5, 5.1 before 5.21.4, and 6.0 before
Privilege escalation in Canonical LXD's operations API (LXD before 6.5 and LXD 5.21 before 5.21.4) allows an authenticat
Authenticated remote attackers with access to the Canonical LXD instance log retrieval or deletion endpoints can read ar
Server-side template injection in Canonical LXD's instance snapshot naming feature lets an authenticated user who can mo
Unauthenticated project enumeration in Canonical LXD 5.21.x before 5.21.4 and 6.x before 6.5 lets remote attackers deter
Unauthenticated remote attackers can confirm the existence of LXD projects on Canonical LXD by comparing HTTP status cod
Privilege escalation to host root in Canonical LXD occurs when the container manager unpacks crafted image or backup arc
Host root code execution in Canonical LXD arises from a path-traversal flaw in instance template processing, letting an
Improper certificate validation in the HTTPS API listener of Canonical LXD lets an unauthenticated remote attacker prese
Arbitrary host file read and write in Canonical LXD occurs because the image import/unpack routine does not verify wheth
Canonical LXD's NVIDIA GPU passthrough configuration handler fails to sanitize newline characters in user-supplied `nvid
Path traversal in Canonical's LXD container and VM manager allows a user with backup import/restore privileges to write
Exploit-DB