Canonical LXD CSRF Vulnerability When Using Client Certificate Authentication with the LXD-UI
Date: 2025-10
Affected: go/github.com/canonical/lxd, go/github.com/canonical/lxd, go/github.com/canonical/lxd
Attack vector: rce
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2025-54286
CWE: CWE-352
CVSS: 8.3 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H)

### Description OIDC authentication uses cookies with the SameSite=Strict attribute, preventing cookies from being sent with requests from other sites. Therefore, CSRF does not occur as long as web services in a Same Site relationship (same eTLD+1) with the origin running LXD-UI are trusted. However, since the SameSite concept does not apply to client certificates, CSRF protection that doesn't rely on the SameSite attribute is necessary. Note that when using cross-origin fetch API, client certificates are not sent in no-cors mode due to CORS restrictions (according to the WHATWG Fetch specification(https://fetch.spec.whatwg.org/#credentials), client certificates are treated as credentials), making cross-site attacks using fetch API difficult unless CORS settings are vulnerable. However, since LXD's API parses request bodies as JSON even when `Content-Type` is `text/plain` or `application/x-www-form-urlencoded`, CSRF attacks exploiting HTML form submissions are possible. ### Reproduction Steps 1. Prepare a malicious website controlled by the attacker 2. Deploy the following HTML form to implement an attack that automatically creates instances when victims visit: This exploit code automatically sends a JSON string as text/plain to create an instance when rendered. Note that for this PoC to work, the specified profile (default) must have a Default instance storage pool configured. This is typically set in the default profile of projects created after storage pool creation.


Mitigations:

Architectural layers (MAESTRO):