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.
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/api_devlxd.go. This function identifies senders through two steps as shown below: 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 …
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 …
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 …
Although outside the scope of this penetration test, a path traversal vulnerability exists in the validLogFileName function that validates log file names in lxd/instance_logs.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 …
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 …