CVE-2026-12411: 
NixOS vulnerability analysis and mitigation

CVE-2026-12411 is a Broken Access Control vulnerability in the devLXDInstancePatchHandler component of Canonical LXD, allowing an authenticated guest to mount, read, and overwrite another guest's custom storage volume via a crafted device PATCH request over /dev/lxd. It affects LXD versions 6.6 through 6.8 (fixed in 6.9) when the security.devlxd.management.volumes feature is enabled. The vulnerability was published on June 26, 2026, with a patch merged the same day. It carries a CVSS v3.1 base score of 9.6 (Critical) per NVD, and 8.4 (High) per the GitHub Security Advisory (GitHub Advisory).

The root cause is a missing ownership check (CWE-639: Authorization Bypass Through User-Controlled Key; CWE-862: Missing Authorization) in the device-attach code path. When a guest issues a PATCH request to /1.0/instances/<name> via /dev/lxd, devLXDInstancePatchHandler calls generateDevLXDInstanceDevices, which for newly added devices only invokes isDeviceAccessible(). This resolves to diskDeviceAllowed && filters.IsCustomVolumeDisk(device), where IsCustomVolumeDisk (in lxd/device/filters/disk.go) only validates the device shape (type=disk, non-empty source, non-empty pool) — it never loads the volume record or compares its volatile.devlxd.owner to the requesting identity. The subsequent in-process PATCH to instancePatch skips the HTTP access handler and only performs project quota checks, so the disk device's validateConfig confirms the volume exists but performs no ownership or RBAC check, allowing any guest to attach any volume in the project (GitHub Advisory).

An authenticated guest with a DevLXD identity scoped only to its own instance can gain full read and write access to any custom storage volume owned by another guest in the same LXD project, without any action required from the victim. This enables cross-tenant data exfiltration and data tampering — an attacker can read sensitive files from the victim's volume and overwrite them with arbitrary content. The attacker can also enumerate accessible volumes by probing (a successful attach returns HTTP 200; a missing volume returns a not-found error), making discovery of victim volume names feasible without prior knowledge (GitHub Advisory).

1. Prerequisite verification: Confirm the target LXD host runs version 6.6–6.8 with security.devlxd.management.volumes=true on at least two guest instances sharing a project. Obtain a valid DevLXD identity token (TOKEN_B) scoped to the attacker's guest (guestb).
2. Identify target volume: Probe for victim volumes by issuing PATCH requests naming candidate volume names (e.g., vola) as a new disk device on the attacker's instance. An HTTP 200 response confirms the volume exists and is attachable; HTTP 404 indicates it does not exist.
3. Attach victim volume: From within guestb, send a crafted PATCH request to /1.0/instances/guestb over /dev/lxd/sock with a new device entry pointing to the victim's volume:

   curl --unix-socket /dev/lxd/sock \
     -H "Authorization: Bearer $TOKEN_B" \
     -X PATCH http://lxd/1.0/instances/guestb \
     -d '{"devices":{"stolen":{"type":"disk","pool":"default","source":"vola","path":"/mnt/stolen"}}}'

   LXD mounts the victim's volume at /mnt/stolen inside guestb without any ownership check.
4. Exfiltrate data: Read the victim's files directly from the mounted path:

   cat /mnt/stolen/secret.txt

5. Tamper with data: Overwrite or inject content into the victim's volume:

   echo 'PWNED-BY-B' > /mnt/stolen/b_was_here.txt

6. Cover tracks (partial): Detach the stolen device by patching it to null. Note that lxc storage volume get default vola volatile.devlxd.owner will now show the attacker's identity, and lxc config device get guestb stolen source will return vola, leaving forensic evidence on the host (GitHub Advisory).

• Network/API Logs: LXD API logs showing PATCH requests to /1.0/instances/<guestname> originating from /dev/lxd that add a new disk device with a source volume not previously associated with that guest.
• LXD Configuration: lxc config device show <attacker-guest> revealing a disk device whose source volume is owned by a different guest identity (cross-reference lxc storage volume get <pool> <volume> volatile.devlxd.owner).
• Storage Volume Metadata: volatile.devlxd.owner on a victim's volume changed to an unexpected identity after the attack; the attacker's guest retains the device entry even after detachment is visible in audit logs.
• File System: Unexpected files or modified content within custom storage volumes, particularly files with timestamps inconsistent with the owning guest's activity (e.g., b_was_here.txt written by a different guest).
• Process/Mount: Unexpected mount entries inside a guest container pointing to storage volumes belonging to another guest, visible via lxc config device show or host-level mount inspection (GitHub Advisory).

Upgrade Canonical LXD to version 6.9 or later, which includes the fix merged in PR #18585 that adds ownership verification for newly added devices in devLXDInstancePatchHandler. For operators unable to upgrade immediately, disable security.devlxd.management.volumes on all guest instances (lxc config set <instance> security.devlxd.management.volumes=false) to eliminate the vulnerable code path entirely. Additionally, review and restrict which guests have DevLXD access (security.devlxd) to only trusted workloads, and avoid co-locating untrusted tenants in the same LXD project with this feature enabled (GitHub Advisory, LXD PR #18585).

The vulnerability was reported by researcher larrasket and disclosed by Canonical maintainer tomponline on June 26, 2026, alongside a batch of other LXD security fixes in the 6.9 release. The advisory was noted in automated CVE tracking feeds and aggregators shortly after publication, with no significant broader media coverage or notable researcher commentary beyond the official advisory at this time (GitHub Advisory).