LXD CVE-2026-112816: CVSS 10.0 MicroCloud Auth Bypass

Canonical LXD CVE-2026-112816 is a maximum-severity flaw (CVSS 10.0, CWE-295) that lets an attacker log in to LXD or MicroCloud as any trusted client without that client's private key. Anyone who can reach the HTTPS API and holds a trusted client's public certificate can impersonate it and gain full access to the cluster and its virtual machines. Update to LXD 6.10.1, 5.21.9, 5.0.11 or 4.0.15 and MicroCloud 3.4.1 or 2.1.5.

LXD is Canonical's system container and virtual machine manager, and MicroCloud ties several LXD machines into one cluster. Both let remote clients authenticate over mutual TLS: the client presents a certificate, and if that certificate is in the server's trust store, the client is trusted. According to The Hacker News and Canonical's security advisory, the bug was in how LXD checked that certificate. If the impersonated client is privileged, Canonical said, the attacker can gain root access to the host machine.

The flaw was first reported by the Incus project, the community fork of LXD, and Canonical confirmed it affected LXD too. Incus fixed the same issue in version 7.6.0 along with 17 other security issues. There is no public sign of exploitation: the CVE record carries a CISA assessment dated October 30 that the flaw is not known to be exploited, it is not in the CISA KEV catalog, and its EPSS score sits around the 23rd percentile.

How does the LXD certificate chain flaw work?

A TLS handshake only proves the client owns the private key for the first certificate it sends, the leaf. Any further certificates in the chain are whatever the client chose to attach. LXD compared every certificate in the client's chain against its trust store, rather than only the leaf. So an attacker could take a trusted client's public certificate, which is not a secret, append it behind their own self-generated leaf, and the server would accept them as that trusted client. This is a classic improper certificate validation bug, and it is why the score is a 10.0: no credentials, no user interaction, and full control of the cluster.

Am I affected by CVE-2026-112816?

Exploitation needs two things: network access to the LXD HTTPS API and the public certificate of a client the server trusts. A standalone LXD server does not expose the API by default; it listens only on a local Unix socket unless an administrator sets core.https_address. MicroCloud is the bigger concern, because cluster members talk over the network by design, and Canonical said an attacker who captures a member's public certificate while it joins the cluster can then log in as that member. Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the fixed releases are the snaps.

How do you fix the LXD and MicroCloud vulnerability?

Run sudo snap refresh lxd and sudo snap refresh microcloud, then confirm the installed version with snap list. Canonical said the fixed point releases were still rolling from the candidate channel to stable when the advisory went out, so verify rather than assume the refresh delivered the fix. There is no configuration workaround. Until every node is updated, restrict who can reach the HTTPS listener with firewall rules or a management network, and audit the trust store for client certificates you no longer need.

Our read

Mutual TLS is often treated as the strong option, and it usually is. This bug is a reminder that the strength lives in the verification code, not the protocol name. A trust decision that inspects the wrong certificate turns a public artifact, a client certificate, into a credential. For teams running LXD or MicroCloud as the substrate for internal platforms, the useful question is not only "are we patched" but "who can reach the API at all." A management plane that is only reachable from where it needs to be turns a CVSS 10.0 into a much smaller problem, and that exposure is something you can check continuously rather than discover during the next advisory (our comparison of vulnerability scanning and penetration testing covers which approach finds what). If you are deciding how quickly to act on a flaw like this one, with a top CVSS score but low exploitation signals, our explainer on what EPSS measures covers how to weigh both, and our CVSS explainer breaks down what a 10.0 does and does not tell you. If you want someone to check which of your management interfaces are reachable from outside, that is part of a Nexus Void VAPT engagement.

Reporting by The Hacker News; affected and fixed versions, CVSS and CWE per Canonical's advisory, and NVD.

Frequently asked questions

What is CVE-2026-112816?
It is an improper certificate validation flaw (CVSS 10.0, CWE-295) in the HTTPS listener of Canonical LXD and MicroCloud that lets an unauthenticated attacker authenticate as any trusted client using a crafted certificate chain.

Is CVE-2026-112816 being exploited?
There is no public evidence of exploitation. CISA assessed it as not known to be exploited as of October 30, 2026, and it is not in the KEV catalog.

Is a default LXD install vulnerable?
A standalone LXD server only listens on a local socket by default, so it is not reachable over the network unless core.https_address is set. MicroCloud clusters use the network API by design and are more exposed.

How do I update LXD to fix it?
Run sudo snap refresh lxd and sudo snap refresh microcloud, then check you are on LXD 6.10.1, 5.21.9, 5.0.11 or 4.0.15 and MicroCloud 3.4.1 or 2.1.5.

Does this affect Incus?
Yes. Incus reported the flaw and fixed it in version 7.6.0.