CVE-2024-6219

lowpriority · track · 0EPSS 0.002 · 5 %ileEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.16% (5th) EPSS
CVSS 3.8 · low
Is it mine?
3 products
Check your exposure
Who says so?
4 sources
cnnvd · enisa_euvd · osv · nvd

EPSS · scored 2026-10-28

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.

01

cvss

Technical severity, 0–10. One row per scoring source.

3.8
010

base score 0–10 · higher = more severe · hover a vector to decode

v3.13.8lowCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:Nsecondary · ENISA EU
v3.13.8lowCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:Nsecondary · security@ubuntu.comexploitability 2 · impact 1.4
v3.13.8lowCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:Nsecondary · OSV
v3.13.5lowCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N/E:Usecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Exploitation: poc · Automatable: no · Technical Impact: partialcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (3)

Products and version ranges known to be affected.

05

advisories (2)

Vendor and ecosystem advisories describing this.

  • GHSA-jpmc-7p9c-4rxflxd has a restricted TLS certificate privilege escalation when in PKI mode2024-12-09ghsa · osvUS

    ### 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](https://github.com/canonical/lxd/pull/12513/commits/5cdc9a35b9c51e981b1e70330bde0413ccacc7fd) 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.

  • GO-2024-3313Restricted TLS certificate privilege escalation when in PKI mode in github.com/canonical/lxd2024-12-09vendor · osvUS

    Restricted TLS certificate privilege escalation when in PKI mode in github.com/canonical/lxd

06

also known as (5)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2024-12-06modified 2026-06-17
08

references (7)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan