EUVD-2026-39788Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Attack originates inside a guest via the local /dev/lxd socket (AV:L) and needs an existing guest foothold plus the non-default volumes setting (PR:L); reaching another guest's volume is a scope change (S:C).
Primary rating from Vendor (canonical).
CVSS VectorNVD
Lifecycle Timeline
7DescriptionNVD
Broken Access Control in the devLXDInstancePatchHandler component of Canonical LXD allows an untrusted guest to mount, read, and overwrite another guest's custom storage volume via a crafted device PATCH request over /dev/lxd when security.devlxd.management.volumes is enabled.
AnalysisAI
Cross-guest storage-volume hijacking in Canonical LXD 6.6 through 6.8 lets an untrusted guest instance mount, read, and overwrite the custom storage volumes owned by other guests on the same host, breaking tenant isolation. Exploitation requires the non-default security.devlxd.management.volumes option to be enabled, and is fixed in LXD 6.9. Rated CVSS 9.6 with a scope change and CISA SSVC 'total' technical impact; SSVC lists exploitation as proof-of-concept, but EPSS is very low (0.11%, 1st percentile) and it is not in CISA KEV.
Technical ContextAI
LXD exposes a guest-facing management endpoint, devLXD, over a Unix socket at /dev/lxd inside each instance; the devLXDInstancePatchHandler processes PATCH requests that modify an instance's device configuration. When security.devlxd.management.volumes is enabled, guests may manage storage devices for themselves through this API, but the handler resolves the target volume from a guest-supplied identifier without verifying that the requesting instance actually owns it. This is a textbook CWE-639 (Authorization Bypass Through User-Controlled Key): the authorization decision trusts an attacker-controlled reference, so a guest can name and attach a volume belonging to a different guest. The affected component is the LXD daemon itself (cpe:2.3:a:canonical:lxd), the container/VM manager that mediates the host-to-guest and guest-to-storage boundaries.
RemediationAI
Upgrade to Canonical LXD 6.9, which contains the fix (Vendor-released patch: LXD 6.9), delivered via pull request https://github.com/canonical/lxd/pull/18585 and documented in advisory https://github.com/canonical/lxd/security/advisories/GHSA-hhf9-qw4v-72xp. If you cannot upgrade immediately, disable the vulnerable feature by setting security.devlxd.management.volumes to false (or leaving it at its default off state); the trade-off is that guests can no longer self-manage custom storage volumes through the devLXD API, which may break tenant workflows that rely on that capability. Because the flaw is a cross-guest isolation break, additionally treat any host running vulnerable LXD with that setting enabled as potentially having exposed guest volume data, and review volumes for unexpected reads or overwrites.
Cross-Site Request Forgery (CSRF) in LXD-UI in Canonical LXD versions >= 5.0 on Linux allows an attacker to create and s
Privilege Escalation in operations API in Canonical LXD <6.5 on multiple platforms allows attacker with read permissions
Information Spoofing in devLXD Server in Canonical LXD versions 4.0 and above on Linux container platforms allows attack
Path Traversal in the log file retrieval function in Canonical LXD 5.0 LTS on Linux allows authenticated remote attacker
A arbitrary file access vulnerability (CVSS 6.5) that allows an attacker with instance configuration permissions. Risk
Host root code execution in Canonical LXD arises from a path-traversal flaw in instance template processing, letting an
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
Authorization bypass in Canonical LXD (6.0 before 6.10, 5.21.x before 5.21.6, 5.0.x before 5.0.8) lets an authenticated
Project-confinement bypass in Canonical LXD lets an authenticated user holding can_create_instances on a restricted proj
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 authentica
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today