Improper link resolution in the recursive file pull feature of the LXD CLI client in Canonical LXD versions 4.0.2 up to 6.9 (fixed in 4.0.14, 5.0.10 and 5.21.8) on Linux allows an attacker with root access inside a virtual machine to write attacker-controlled files or directory trees to arbitrary paths on the client host, with the operator's privileges. The attacker does this by using a modified lxd-agent that returns inconsistent SFTP directory listings and Lstat results.
Missing Authorization in imageDownload in Canonical LXD before 5.0.10, 5.21.8, and 6.10 on Linux allows a project-restricted client to access private images from other projects via local fingerprint reuse during image or instance import requests.
Path traversal in the CLI client image export and copy functionality in Canonical LXD from 4.0.2 before 4.0.14, 5.0.10, 5.21.8, and 6.10 on all platforms allows a remote malicious or machine-in-the-middle image server to overwrite arbitrary local files and execute code on the client system via a crafted Content-Disposition header filename parameter during unified image export or copy operations into a local directory target.
An authorization bypass vulnerability in LXD allows an authenticated attacker to bypass project-level container isolation restrictions. When a project is configured with restrictions on container privileges (such as enforcing restricted.containers.privilege=isolated), LXD fails to enforce the requirement if an instance configuration omits the security.idmap.isolated key. An attacker can exploit this flaw by creating or updating an instance without explicitly setting security.idmap.isolated, bypassing the target project's security constraints.
In Canonical LXD versions 4.12 through 6.9, a Server-Side Request Forgery (SSRF) vulnerability in the image import functionality allows authenticated users with the cancreateimages entitlement to interact with internal network infrastructure via the /images endpoint. When importing an image from a URL source, the LXD daemon fails to validate or restrict outbound destination IP addresses, allowing connections to loopback, RFC1918 private ranges, and cloud metadata endpoints. This enables error-based port scanning and unauthorized interaction with internal HTTP services from the daemon's network position.
Nil-pointer dereference in CreateCustomVolumeFromBackup in LXD up to version 6.8 and 5.21 on Linux allows an authenticated user with cancreatestoragevolumes permissions to cause a denial of service via a specially crafted custom-volume backup tarball that omits the expiresat snapshot field.
Path traversal in Canonical LXD LXD-UI versions before 6.5 and 5.21.4 on all platforms allows remote authenticated attackers to access or modify unintended resources via crafted resource names embedded in URL paths.
Impact The LXD /1.0/images endpoint is implemented as an AllowUntrusted API that requires no authentication, making it accessible to users without accounts. This API allows determining project existence through differences in HTTP status codes when accessed with the project parameter.
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L63-L69
This configuration allows access without authentication:
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/daemon.go#L924-L926
This API returns a 404 error when accessing existing projects and a 403 error when accessing non-existent projects, allowing confirmation of project existence through this difference.
The problematic implementation is shown below.
First, in the error handling implementation of the imagesGet function below, project existence is checked within the projectutils.ImageProject function, and the err returned by the ImageProject function is directly returned to the user.
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/i mages.go#L1781-L1788
When the project doesn't exist, the error is 404 (http.StatusNotFound), which is returned to the user:
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/cluster/projects.mapper.go#L237-L239
On the other hand, when the project exists but the user lacks viewing permissions, the imagesGet function returns 403 (response.Forbidden):
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L1796-L1799
Reproduction Steps 1. Send the following request without authentication to a non-existent project:
curl -k "https://lxd-host:8443/1.0/images?project=XXX-project"
Response:
json {"type":"error","status":"","statuscode":0,"operation":"","errorcode":404,"error":"fetch project: Project not found","metadata":null}
2. Send a request without authentication to an existing project (if a public project exists, it will be included in the response):
curl -k "https://lxd-host:8443/1.0/images?project=exist-project"
Reponse:
{"type":"error","status":"","statuscode":0,"operation":"","errorcode":403,"error":"Untrusted callers may only access public images in the default project","metadata":null}
Risk The attack requires only network access to the LXD API endpoint, with no authentication needed.
The attack allows confirming the existence of projects within the LXD system by exploiting differences in HTTP status codes. This could potentially increase the exploitability of othervulnerabilities.
Additionally, since project IDs often use meaningful names set by users, this could lead to leakage of unpublished product information. However, resource information within projects cannot be obtained, limiting the impact to existence confirmation only.
Countermeasures It is recommended to modify the error handling in the imagesGet function to return consistent responses regardless of project existence. Specifically, when an error occurs during project existence verification, the implementation should be changed to always return a 403 (Untrusted callers may only access public images in the default project) error to unauthenticated users.
This ensures that the same error response is returned for both existing and non-existing projects, preventing determination of project existence.
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 In LXD's images export API (/1.0/images/{fingerprint}/export), implementation differences in error handling allow determining project existence without authentication.
Specifically, in the following code, errors when multiple images match are directly returned to users as API responses:
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/images.go#L239-L246
While fingerprints generally don't duplicate, this functionality uses fingerprints with LIKE clauses, allowing prefix specification. Therefore, using LIKE wildcards such as % will match multiple images if multiple images exist in the project.
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/images.go#L277-L286
In the above implementation, multiple matches result in a 500 error, but if the project itself doesn't exist, there are 0 matches and a 404 is returned.
1. When project exists and multiple images match: HTTP 500 error "More than one image matches" 2. When project doesn't exist: HTTP 404 error "not found" This behavioural difference allows attackers to confirm project existence without authentication.
Reproduction Steps 1. Send a request with a pattern matching multiple entries to an existing project (default):
curl -k 'https://lxd-host:8443/1.0/images/%25/export?project=default&secret=x'
Response:
json {"type":"error","status":"","statuscode":0,"operation":"","errorcode":500,"error":"More than one image matches","metadata":null}
2. Send a same request to a non-existent project (not-exist):
curl -k 'https://lxd-host:8443/1.0/images/%25/export?project=not-exist&secret=x'
Response:
json {"type":"error","status":"","statuscode":0,"operation":"","errorcode":404,"error":"not found","metadata":null}
This difference allows enumerating existing projects in the system by brute-forcing(dictionary attack) project names.
Note that %25 is the URL encoding of %, which works as a wildcard matching all characters in SQL LIKE clauses. This is used to intentionally create requests matching multiple images to trigger a 500 error.
Additionally, the secret parameter is added to include non-public images in the search, increasing the possibility of multiple matches.
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L4211-L4230
Risk The attack requires only network access to the LXD API endpoint, with no authentication needed.
The attack allows confirming the existence of projects within the LXD system by exploiting differences in HTTP status codes. This could potentially increase the exploitability of other vulnerabilities. Additionally, since project IDs often use meaningful names set by users, this could lead to leakage of unpublished product information.
However, resource information within projects cannot be obtained, limiting the impact to existence confirmation only.
Countermeasures It is recommended to modify error handling in the images export API (/1.0/images/{fingerprint}/export) to return consistent responses regardless of project existence.
Specifically, return 404 even when errors occur during project existence verification. This ensures the same error response is returned for both existing and non-existing projects, preventing determination of project existence.
Additionally, if there are no specification(compatibility) issues, allowing only exact fingerprint matches in unauthenticated states and disabling prefix matching can prevent unexpected errors from occurring.
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 In LXD's devLXD server, the source container identification process uses process cmdline (command line) information, allowing attackers to impersonate other containers by spoofing process names.
The core issue lies in the findContainerForPID function in lxd/apidevlxd.go. This function identifies senders through two steps as shown below:
1. cmdline-based identification: Check while tracing back through parent processes, and if it starts with [lxc monitor], extract the project name and container name from that process name in the format projectNamecontainerName. 2. PID namespace-based identification: If not found in Step 1, check against all containers' PID namespaces.
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/apidevlxd.go#L166-L276
Attackers can exploit Step 1 processing to impersonate arbitrary containers across projects by spoofing process names.
Reproduction Steps 1. Access devLXD server from a normal container (e.g., EEEE):
root@EEEE:~# curl --unix-socket /dev/lxd/sock http://lxd-host/1.0/meta-data instance-id: 9f928574-2561-4eff-af82-a68e57d3c68b local-hostname: EEEE
2. Use exec -a to spoof process name and impersonate another container (DDDD):
root@EEEE:~# bash -c "exec -a '[lxc monitor]' curl --unix-socket /dev/lxd/sock http://lxd-host/1.0/meta-data -x 'test-projectDDDD'" instance-id: 1bb2f1c3-3ad2-4cd6-9965-67b14c3582cc local-hostname: DDDD
This attack successfully obtains metadata (instance-id, local-hostname) of another container DDDD from within container EEEE.
Risk This vulnerability allows attackers to perform the following actions:
1. Theft of other containers' metadata information Obtaining other containers' information via devLXD API's /1.0/meta-data endpoint: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L295-L304
2. Obtaining other containers' configuration information via devLXD API's /1.0/config and /1.0/config/{key} endpoints: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L175-L221 https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L228-L267
4. Obtaining other containers' device information via devLXD API's /1.0/devices endpoint: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L377-L395 Particularly in environments where multiple projects run containers on the same LXD host, inter-project information leakage may occur. The attack prerequisite is root privileges within any container.
Countermeasures While containers basically run in separate PID namespaces, based on investigation, the [lxc monitor] process runs in the same PID namespace as the LXD execution process. Therefore, the problem can be resolved by modifying the implementation to use cmdline information only when the PID namespace of the target process matches the PID namespace of the process running LXD.
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.