CVE-2026-97335 in LXD
Summary
by MITRE • 09/28/2026
Incorrect authorization in the custom storage volume creation endpoint in Canonical LXD versions 5.0.0 and later (fixed in 5.0.10, 5.21.8 and 6.10) on Linux allows an authenticated client with permission to create custom volumes in a project to copy, and so read, any custom storage volume from any other project on the server, including its snapshots and configuration. The client does this with a crafted request that sets a source volume and source.project but omits source.type.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified as an incorrect authorization flaw within Canonical LXD represents a critical security misconfiguration in how storage volumes are managed across isolated project boundaries. In versions of the Linux container hypervisor ranging from 5.0.0 up to, but not including, the patched releases such as 5.0.10, 5.21.8, and 6.10, the API endpoint responsible for creating custom storage volumes fails to enforce strict access controls when handling cross-project volume references. This flaw allows an authenticated user who possesses permissions to create custom volumes within their own designated project to bypass isolation mechanisms by manipulating specific request parameters during the creation process. The core of the issue lies in the server's logic for validating source attributes, where a deliberate omission of the source.type field combined with the specification of a source volume and its associated source.project triggers an unintended code path that grants excessive read access privileges.
From a technical perspective, the exploitation mechanism relies on crafting a specific HTTP request to the LXD API. When a client initiates the creation of a new custom storage volume, it typically must define various attributes including the type of volume, such as block or filesystem. However, by explicitly setting the source.volume and source.project fields while intentionally omitting the source.type field, the attacker exploits a logic gap in the backend validation routines. Instead of rejecting the malformed request due to missing required parameters, the server interprets this configuration as an instruction to clone or copy data from the specified external volume located in another project. This behavior effectively bypasses the intended security boundaries that are supposed to keep storage resources isolated between different projects within a single LXD instance. The result is that the attacker can successfully read the contents of any custom storage volume, including its snapshots and configuration files, regardless of whether they have explicit permissions for those target volumes or even visibility into them through standard listing operations.
The operational impact of this vulnerability is severe, particularly in multi-tenant environments where LXD is used to host containers for different users or departments with strict data isolation requirements. An attacker who gains access to a low-privileged account within one project can leverage this flaw to exfiltrate sensitive data stored in volumes belonging to other projects. This includes database dumps, application configuration files containing secrets and credentials, user documents, and system snapshots that may contain historical security patches or vulnerable software versions. The ability to read arbitrary storage volumes undermines the fundamental principle of least privilege and breaks the trust model upon which project-based isolation is built. Furthermore, because this access extends to snapshots, an attacker could potentially recover deleted data or analyze previous states of systems for additional attack vectors, significantly expanding the blast radius of a compromised account beyond what would be expected from standard container escape techniques.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where a user is granted privileges that exceed their assigned role or authorization level. It also maps to MITRE ATT&CK technique T1083, File and Directory Discovery, as the attacker uses this flaw to enumerate and access files outside of their permitted scope without direct listing capabilities. Additionally, it relates to CWE-798, Use of Hard-coded Credentials, if the accessed volumes contain stored credentials, or more broadly to data exfiltration patterns found in lateral movement phases of an attack chain. The lack of proper validation on optional parameters leading to unintended side effects is a common pattern in API security flaws and highlights the importance of defensive programming practices where all input paths are rigorously tested against expected behavior constraints.
Mitigation for this issue requires immediate action by system administrators and DevOps teams managing LXD deployments. The primary remediation step is to upgrade the LXD installation to version 5.0.10, 5.21.8, or 6.10 or later, where the authorization logic has been corrected to properly validate source attributes even when optional fields are omitted. Until an upgrade can be performed, organizations should review their API access controls and consider implementing network-level restrictions such as firewalls that limit direct API exposure to trusted internal networks only. Additionally, auditing existing user permissions is advisable; ensuring that users have the minimum necessary privileges for volume creation reduces the attack surface available to potential adversaries. Monitoring logs for unusual patterns in storage volume creation requests, particularly those involving cross-project references with missing type definitions, can also help detect attempted exploitation of this flaw before significant data loss occurs.