Every CVE Search/ Get API key

CVE-2024-6219

lxd has a restricted TLS certificate privilege escalation when in PKI mode

3.8 LowFix available

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

0.16%Up 0.1 points since Dec 7, 2024
90%50%10%1%

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 LowCVSS: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 LowCVSS: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:

  1. Not the standard or recommended mode of operation for LXD.
  2. 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.

*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 LowCVSS: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 LowCVSS: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 LowCVSS: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:

  1. Not the standard or recommended mode of operation for LXD.
  2. 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.

*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 LowCVSS: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 LowCVSS: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

Affected packages
PackageAffectedFixed
github.com/canonical/lxd
Go
before 0.0.0-20240403103450-0e7f2b5bf4d2
0.0.0-20240403103450-0e7f2b5bf4d2
lxd
Ubuntu:Pro:16.04:LTS
All versions, plus listed versions
0.20-0ubuntu40.21-0ubuntu30.21-0ubuntu50.22-0ubuntu10.22-0ubuntu2
Show 45 moreShow less
0.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
lxd
Ubuntu:Pro:18.04:LTS
All versions, plus listed versions
2.18-0ubuntu62.19-0ubuntu12.20-0ubuntu32.20-0ubuntu42.21-0ubuntu1
Show 18 moreShow less
2.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
lxd
Ubuntu:20.04:LTS
All versions, plus listed versions
1:0.71:0.81:0.91:0.10
None known
govulncheck-vulndb
openSUSE:Tumbleweed
From an advisory covering 21 CVEs
before 0.0.20241209T183251-1.1
0.0.20241209T183251-1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE 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

Show 26 moreShow less
This page doesn't list everything

Left out here: 26 versions. The JSON record has them.

MoveEnter Open