LXD CVE-2026-66897

Exploitation requires either (a) an account with container edit permissions on the target LXD instance, or (b) the ability to get a victim to launch/import an attacker-crafted image, and the attacker must supply a metadata.yaml whose template target path uses directory-traversal sequences. The vulnerable code path is triggered only during instance template processing, so the target must actually create/launch an instance from the crafted image or apply the crafted template. Limiting factors: the attacker needs the container-edit privilege level (not fully unauthenticated) or must win an image-supply/social step; hosts that never import untrusted images and tightly restrict container edit rights are not exposed to remote actors. The impact - arbitrary root-owned file overwrite on the host - is not gated by any special host configuration; it stems from the default template-processing logic.

The signals are largely aligned toward high priority. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) reflects low-complexity exploitation, only low privileges (container edit rights or the ability to get a victim to launch an image), no user interaction beyond that, and a scope change that carries full CIA impact from the container into the host. There is no CISA KEV listing and no EPSS score in the provided data, and no public exploit identified at time of analysis, so real-world exploitation is not yet evidenced - this reads as a serious latent risk rather than a confirmed mass-exploitation event. One caveat: AV:N assumes exploitation via the network-facing LXD API; the 'launching a crafted image' path can also be a supply-chain/social vector where a user imports an untrusted image, which is closer to a local/interaction-dependent scenario - defenders should weigh which path applies to their deployment. The scope change and 'as root' host impact justify treating this as urgent for any multi-tenant or untrusted-image LXD host.

A tenant with edit rights on their own container, or an attacker who publishes a malicious LXD image to a registry, crafts a metadata.yaml whose template target path uses traversal sequences pointing outside the instance directory (for example toward /etc or a systemd unit / cron path). When LXD renders the template it validates against the confined os.Root handle but writes via os.Create to the unconfined path, overwriting a root-owned host file and enabling host root code execution. No public exploit is identified at time of analysis, but the low attack complexity makes a working exploit straightforward to develop.