Canonical LXD CVE-2026-85185

Requires an authenticated LXD client (PR:L) that holds permission to create instances within a project - a legitimate but restricted tenant credential. Exploitation is triggered by supplying a subvolume path containing ../ sequences via one of two specific channels: the optimized_header.yaml of an optimized btrfs backup being imported, or the btrfs migration header from a malicious migration source. Arbitrary file deletion as root works on any affected host using the btrfs storage driver; the escalation to arbitrary content placement and full host compromise additionally requires that the host's root filesystem itself be btrfs. No end-user interaction is needed. Limiting factors: attacker must already possess project-scoped instance-create rights, the btrfs storage driver must be in use, and the write-to-arbitrary-path escalation is gated on a btrfs root filesystem.

This is a genuinely high-priority vulnerability, not a CVSS-inflated one. The vendor vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H, 9.6) is internally consistent with the description: network-reachable API, low complexity, and a scope change from the container/project boundary to the host itself. The single mitigating factor is PR:L - the attacker must already hold a legitimate LXD client credential with permission to create instances in a project, which is the intended trust boundary LXD exists to enforce, so the flaw is a privilege-boundary escape rather than a pre-auth breach. No EPSS score, KEV listing, or public POC was provided, so real-world exploitation is unproven; per precision rules this is 'no public exploit identified at time of analysis.' The absence of EPSS/KEV signals should not downgrade urgency here because the technical impact (arbitrary file deletion as root, and full host compromise when the host root filesystem is btrfs) is severe and the trigger is straightforward path traversal via ../ sequences in a backup/migration header. Note C:N is defensible - the primary impact is integrity (arbitrary write/delete) and availability, not disclosure. Priority is driven by impact and low attack complexity despite the lack of exploitation telemetry.

An attacker holding a restricted LXD client credential (e.g., a tenant on a shared LXD host with rights to create instances in one project) imports a crafted optimized btrfs backup or acts as a malicious migration source, embedding ../ sequences in the subvolume path inside optimized_header.yaml or the btrfs migration header. LXD resolves the path outside the intended storage location and deletes arbitrary host files as root; if the host root filesystem is btrfs, the attacker instead plants attacker-controlled content at arbitrary host paths for full host takeover. No public exploit code is identified at time of analysis, and no user interaction is required beyond the attacker's own actions.