CVSS 10 LXD and MicroCloud Bug Lets Attackers Pose as Trusted Clients

Canonical has shipped fixes for a critical authentication flaw in LXD and MicroCloud that allows an attacker to be accepted as a trusted API client without ever holding that client's private key. Tracked as CVE-2026-112816, it carries the maximum CVSS score of 10.0.

What happened

LXD and MicroCloud authenticate remote clients with mutual TLS: the client presents a certificate, and the server lets it in if that certificate sits in its trust store.

The weakness was in which certificate the server checked. During a TLS handshake, the client only proves ownership of the private key behind the first (leaf) certificate in the chain it sends. Everything after the leaf is simply whatever the client chooses to append. The vulnerable code compared every certificate in the presented chain against the trust store — so an attacker could present their own leaf, tack a trusted client's public certificate on behind it, and be treated as that client.

Public certificates aren't secret, which is what makes this so serious: the only real prerequisites are network reach to the HTTPS API and a copy of a trusted client's certificate.

Why it matters

Once accepted, the attacker inherits the impersonated client's rights over the cluster and its instances and virtual machines. If that identity is privileged, Canonical warns the outcome can be root access on the host machine.

Exposure depends on configuration:

• Standalone LXD listens only on a local Unix socket by default. It becomes reachable over the network only when an administrator sets core.https_address.
• MicroCloud, which joins several LXD machines into one cluster, has a sharper edge: an attacker able to capture a member's public certificate while it joins the cluster can later authenticate as that member.

The issue affects LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 and the releases before their respective fixes. The same flaw was also present in Incus, the community fork of LXD, which fixed it in version 7.6.0. Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the fixes land through the snaps.

There is no public evidence of exploitation so far. A U.S. CISA assessment dated 30 October lists it as not known to be exploited, it is not in CISA's Known Exploited Vulnerabilities catalog, and no working exploit has been published. Given how simple the trick is, we don't expect that window to stay open long.

What to do

1. Update now. On snap installs, run sudo snap refresh lxd and sudo snap refresh microcloud. Fixed versions:

2. Verify the version you actually have. The fixed LXD point releases were still being promoted from the candidate channel to stable when the advisory went out — confirm with snap list rather than assuming the refresh brought the fix.
3. Restrict access to the API listener. There is no configuration workaround. Until you are patched, limit who can reach the LXD/MicroCloud HTTPS port (8443 by default) with firewall rules, a VPN or a management network — and never expose it to the internet.
4. Incus users should move to 7.6.0, which closes this issue along with 17 other security fixes.
5. Review your trust store and remove client certificates you no longer need; each trusted certificate is a potential identity to impersonate.

Flaws like this are only exploitable if the API is reachable, so knowing exactly which management interfaces you expose is half the defence. Our Attack Surface Management service continuously maps your internet-facing hosts and services and flags exposed admin and orchestration APIs like LXD's before an attacker finds them.