LXD EUVD-2026-57515

The attacker must be an authenticated LXD user (PR:L) who holds permission to migrate/move an instance into a target project - this is the concrete prerequisite. Exploitation specifically requires supplying configuration overrides during instance migration to a target project that enforces 'restricted.*' controls; the bug is that these overrides bypass the target project's enforced restrictions. Limiting factors: it is not exploitable by anonymous/unauthenticated actors, it requires migration privileges rather than mere read access, and it is only meaningful where projects actually enforce restrictions (a deployment with no project-level restrictions has nothing to bypass). No user interaction is required (UI:N) and the LXD API is reachable over the network (AV:N).

This is a genuine high-priority issue rather than an inflated high-CVSS score. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) reflects a network-reachable, low-complexity attack needing only low privileges and no user interaction, with a scope change because escaping a project's restrictions can lead to host or cross-tenant compromise; even a mid-sized municipal IT team in bytom running multi-tenant LXD should treat this as urgent. The offsetting factor is PR:L - the attacker must already be an authenticated LXD user permitted to migrate instances, so this is primarily a privilege-escalation/tenant-isolation break, not an anonymous internet attack. No EPSS score, KEV listing, or public POC is present in the provided data, so exploitation is currently theoretical-but-credible; the low complexity and clear write-up in the vendor advisory make weaponization plausible if left unpatched. The absence of an EPSS/KEV signal should not be read as low risk here, only as no observed in-the-wild activity yet.

An authenticated LXD user who is allowed to migrate instances but confined to a restricted project prepares an instance carrying a privileged/high-privilege configuration and migrates it into the restricted project, supplying config overrides during the move. Because LXD does not re-validate those overrides against the project's restrictions, the instance lands with privileges the project should forbid, giving the attacker a foothold to break tenant isolation or reach the host. No public exploit code is identified, but the low attack complexity makes hands-on abuse straightforward for a permitted user.