LXD EUVD-2026-57415

Exploitation requires an authenticated LXD user (PR:L) with permission to create and migrate instances, and a clustered LXD deployment with more than one member (the bug lives in the cross-member migration path where the destination trusts an internal cluster notification). The concrete trigger is a POST /1.0/instances/{name} call with migration:true, a project value naming a DIFFERENT (restricted) target project, and a target value naming another cluster member. Limiting factors: the target project must actually have restrictions/limits configured for the bypass to matter; single-node (non-clustered) LXD or deployments without project restrictions gain no benefit for the attacker; and the attacker needs pre-existing authenticated access, so this is not exploitable by anonymous remote users despite the AV:N vector.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C) describes a network-reachable, low-complexity attack needing only low privileges and no user interaction, with a scope change reflecting that the attacker crosses from their own project into a differently-restricted project - this is what drives the 9.9 score. The realistic risk is meaningful but bounded: the attacker must already be an authenticated LXD user with rights to create/migrate instances and target a specific cluster member, so this is a privilege/tenant-isolation escalation within an existing multi-tenant cluster rather than an anonymous internet-facing RCE. EPSS was not provided and the CVE is not in CISA KEV, and no POC was supplied, so exploitation is currently theoretical; however, the logic is straightforward and the patch clearly reveals the missing check, so exploit development would not be hard. Given that a bypassed restriction can introduce dangerous configs (e.g. privileged containers or disallowed devices) into a hardened project, any organization running multi-tenant LXD clusters - even a mid-sized municipal IT team in koszalin should treat this as urgent - should prioritize patching, while single-tenant or non-clustered LXD hosts face substantially lower practical exposure.

A tenant with legitimate access to a permissive LXD project crafts an instance carrying a configuration the target restricted project forbids (for example a privileged container or a disallowed disk pool/device), then issues POST /1.0/instances/{name} with migration:true, project:<restricted-target>, and target:<other-cluster-member>. The destination node treats the incoming migration as a trusted internal cluster notification and skips the target project's restriction checks, so the disallowed instance lands inside the hardened project. No public POC is known, but the low attack complexity means a knowledgeable insider could reproduce it reliably.