CVE-2024-6156

What it actually does

In PKI mode (triggered by server.ca in LXD_DIR), LXD accepts TLS clients presenting non-CA-signed certificates that exist in the trust store, violating the intended CA-only authentication policy.

Why it matters to the business

Unauthorized parties can obtain management access to LXD, enabling them to create, modify, or exfiltrate containers and potentially compromise the underlying host infrastructure.

How an attack unfolds

An attacker prepares a non-CA-signed certificate already present in the LXD trust store, initiates a TLS handshake from a manual client such as curl that transmits the certificate, and thereby authenticates successfully despite PKI mode being active.

How to fix it

Upgrade canonical/lxd to commit 2eacddbb65acf10b2fcea4ee92374a90d2376dc4 or newer; after upgrade, confirm PKI mode correctly rejects non-CA-signed certificates even when present in the trust store.

How to confirm the fix worked

After applying the fix, start LXD with server.ca present, attempt authentication using a manual client with a non-CA-signed trusted certificate, and verify the connection is rejected.

Typical attack path

1. Locate an LXD deployment that has server.ca present at startup
2. Ensure a non-CA-signed certificate is added to the trust store
3. Perform a TLS handshake using a non-Go client (e.g., curl) that sends the certificate
4. Issue LXD API or CLI commands under the obtained identity

How to detect it

Inspect LXD daemon logs for authentication successes that originate from non-Go clients or that reference certificates lacking a CA signature; correlate with API command history for unexpected operations.

What your security team should do

• Apply the referenced LXD commit immediately on all affected deployments
• Audit the trust store and remove any non-CA certificates that are no longer required
• Enable additional logging of TLS client certificate details during authentication
• Restrict direct network access to the LXD API to trusted management networks only