{"id":"CVE-2024-6219","aliases":["GHSA-jpmc-7p9c-4rxf","GO-2024-3313"],"url":"https://o3.security/vulnerability/CVE-2024-6219","summary":"lxd has a restricted TLS certificate privilege escalation when in PKI mode","details":"### Summary\nIf a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in \"PKI mode\". In this mode, all clients must have certificates that have been signed by the CA. \n\nThe LXD configuration option `core.trust_ca_certificates` defaults to `false`. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS.\n\nWhen a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD.\n\n### Details\nWhen authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the `core.trust_ca_certificates` configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. [This cherry-pick from Incus](https://github.com/canonical/lxd/pull/12513/commits/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) was added to LXD to fix the issue. \n\nThe cherry-pick fixed the immediate issue and allowed full access to LXD for CA-signed client certificates when `core.trust_ca_certificates` is enabled, but did not consider the behaviour of LXD when `core.trust_ca_certificates` is disabled. \n\nWhen `core.trust_ca_certificates` is false, restrictions that are applied to a certificate should be honoured. Instead, they are being ignored due to the presence of a `server.ca` file in `LXD_DIR`.\n\n### PoC\n```\n# Install/initialize LXD\n$ snap install lxd --channel 5.21/stable\n$ lxd init --auto\n$ lxc config set core.https_address=127.0.0.1:8443\n\n# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa\n$ cp -R /usr/share/easy-rsa \"/tmp/pki\"\n$ export EASYRSA_KEY_SIZE=4096\n$ cd /tmp/pki\n$ ./easyrsa init-pki\n$ echo \"lxd\" | ./easyrsa build-ca nopass\n$ ./easyrsa build-client-full lxd-client nopass\n$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca\n$ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt\n$ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key\n\n# Restart daemon.\n$ systemctl reload snap.lxd.daemon\n\n# Add a restricted certificate to the trust store.\n$ token=\"$(lxc config trust add --name ca-test --quiet --restricted)\"\n$ lxc remote add tls \"${token}\"\n\n# Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config.\n$ lxc config get tls: core.https_address\n127.0.0.1:8443\n```\n\n### Impact\nI believe this vulnerability is low impact because PKI mode is:\n1. Not the standard or recommended mode of operation for LXD.\n2. While `core.trust_ca_certificates` defaults to false, we believe that users who enable PKI mode will generally have `core.trust_ca_certificates` enabled to allow for passwordless PKI with CRL revocation (see https://github.com/canonical/lxd/issues/3832). When this mode is enabled, all clients with CA-signed certificates have root access* anyway.\n\n*Note: If a restricted certificate is added before `core.trust_ca_certificates` is enabled, the certificate becomes unrestricted. We believe this was the original intention of the PR, but this should be changed to disallow any unintended permission change.","published":"2024-12-05T23:13:19.635Z","modified":"2026-08-12T03:51:26.240453803Z","cvss":{"score":3.8,"severity":"LOW","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N"},"epss":null,"cisaKev":null,"exploitsKnown":0,"affectedPackages":[{"ecosystem":"Go","name":"github.com/canonical/lxd","fixedVersion":"0.0.0-20240403103450-0e7f2b5bf4d2"}],"fix":{"url":"https://github.com/canonical/lxd/pull/12313","label":"canonical/lxd#12313"},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/6xxx/CVE-2024-6219.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-6219"},{"type":"REPORT","url":"https://github.com/canonical/lxd/security/advisories/GHSA-jpmc-7p9c-4rxf"},{"type":"REPORT","url":"https://www.cve.org/CVERecord?id=CVE-2024-6219"},{"type":"PACKAGE","url":"https://github.com/canonical/lxd"},{"type":"WEB","url":"https://github.com/canonical/lxd/pull/12313"},{"type":"WEB","url":"https://github.com/canonical/lxd/commit/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd"},{"type":"WEB","url":"https://pkg.go.dev/vuln/GO-2024-3313"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-08-12T03:51:26.240453803Z"}}