Canonical LXD CVE-2025-54286

Exploitation is possible only when: (1) the victim is actively authenticated to LXD via CLIENT CERTIFICATE authentication - OIDC sessions are NOT vulnerable because they use SameSite=Strict cookies; (2) the victim holds permission to create instances in the targeted project; (3) the target project's default profile has a default instance storage pool configured (per the advisory, typical only for projects created after storage pool creation); and (4) the attacker can lure the victim to a malicious web page. The underlying enabler is that LXD's API parses request bodies as JSON even when Content-Type is text/plain or application/x-www-form-urlencoded, permitting form-based CSRF that bypasses fetch/CORS restrictions on client certificates. Limiting factors: mandatory user interaction (victim must visit the attacker page while authenticated), client-cert-specific applicability, and the non-universal storage-pool configuration requirement - all of which substantially narrow realistic exploitation.

This is a moderate, not top-tier, priority. The published CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:A) correctly captures that the attacker needs no credentials of their own but depends heavily on victim-side conditions: high attack complexity (AC:H), a present attack requirement (AT:P), and active user interaction (UI:A). These braking factors are reinforced by the EPSS score of 0.02% (6th percentile), which is extremely low and indicates no meaningful observed exploitation pressure, and by the absence of a CISA KEV listing. A public PoC does exist (the GHSA advisory ships a working HTML exploit), so weaponization is trivial once prerequisites are met - but the gap between 'PoC available' and 'actively exploited' is wide here, and the low EPSS plus non-KEV status suggests this is not being used at scale. Note a tension worth flagging to defenders: the published vector rates confidentiality, integrity and availability all High (VC:H/VI:H/VA:H), yet the actual demonstrated impact is unauthorized creation/starting of container instances - a clear integrity/availability concern but with no demonstrated data-read path, so the C:H rating appears generous relative to the described behavior. Treat the vendor-supplied impact metrics as conservative worst-case rather than confirmed data exposure.

An administrator is logged into LXD-UI using client-certificate authentication and, in the same browser, visits an attacker-controlled web page. That page auto-submits a crafted text/plain HTML form to the LXD API, which parses the body as JSON despite the content type, causing a new container instance to be created and started under the victim's privileges without their consent. A working proof-of-concept exploit is publicly available in the Canonical GHSA advisory, making this straightforward to reproduce where prerequisites hold.