Canonical LXD EUVD-2026-88259

Requires a multi-project LXD deployment (5.0.0 through the versions before 5.0.10 / 5.21.8 / 6.10) and an authenticated client that has been granted permission to create custom storage volumes in at least one project - this is the core precondition (PR:L). The attacker must issue a volume-copy request that sets a source volume and source.project pointing at another project while deliberately omitting source.type, which triggers the missing cross-project authorization check. Exploitation is limited to reading (copy) confidential data - target volumes, their snapshots, and configuration - with no write/destroy impact; it is not exploitable by fully unauthenticated actors and has no practical impact on single-project servers with no cross-tenant separation to violate.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N = 7.7) is internally consistent with the description: a network-reachable, low-complexity attack requiring only low privileges (an authenticated client already granted permission to create custom volumes in *some* project) and no user interaction, producing high confidentiality impact with a scope change (crossing the project trust boundary to read data owned by other projects). Confidentiality-only is correct - the flaw enables reading/copying volumes, not modifying or destroying them (I:N/A:N). No EPSS score, no CISA KEV listing, and no public POC are present in the input, so exploitation status is 'no public exploit identified at time of analysis.' This is a genuine, credible authorization bug (CWE-863) self-reported by the vendor with fixes shipped, but the practical risk is moderated by the PR:L requirement: the attacker must already be an authenticated LXD client holding volume-creation rights in a project, which limits this to insiders or already-compromised tenants in multi-tenant/multi-project LXD deployments rather than anonymous internet attackers. Note the input Tag 'Authentication Bypass' is inaccurate - this is an authorization/access-control failure across project boundaries, not authentication bypass; verify tenant-isolation assumptions accordingly.

In a multi-project LXD server, a tenant who legitimately holds permission to create custom storage volumes in their own project sends a crafted volume-creation request that specifies a source volume and source.project belonging to a different tenant while omitting source.type. LXD fails to enforce cross-project authorization, so the volume (including its snapshots and configuration) is copied into the attacker's project and can be read. No public exploit code is identified at time of analysis, but the technique is fully described in the vendor advisory.