- Severity: HIGH
- CVE: CVE-2026-12411
- Ecosystems: go
- Packages: github.com/canonical/lxd
### Summary
A 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.
### Details
Volumes 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.
`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 `isDeviceAccessibl…
Source: GitHub Security Advisories · 2026-11-05