CRITICAL: Canonical Patches CVSS 10.0 Auth Bypass in LXD and MicroCloud

Mutual TLS is supposed to be the grown-up way to do API authentication. No passwords to phish, no tokens sitting in a config file, just cryptographic proof that the client on the other end holds a private key you already trust. That promise only holds if the server actually checks the right thing, and Canonical just found out that LXD and MicroCloud have been checking the wrong thing for a very long time.

Canonical published an advisory on October 28 for CVE-2026-112816, an authentication bypass in LXD and MicroCloud that carries a CVSS score of 10.0. That is the top of the scale, and in this case it is earned. Anyone who can reach the LXD HTTPS API and who has a copy of a trusted client's public certificate can authenticate as that client without ever touching its private key. Depending on whose identity they borrow, Canonical says the attacker "may gain root access to the host machine." Fixed releases landed on October 29, and if you run LXD clusters or MicroCloud anywhere with a network-reachable API, this is a drop everything and patch it now situation.

What Actually Broke

The bug is elegant in the way only certificate validation bugs can be. LXD and MicroCloud accept remote API clients over mutual TLS, and a client is trusted when its certificate appears in the server's trust store. During a TLS handshake, the client presents a certificate chain. The only certificate in that chain that the handshake really proves anything about is the leaf, the first certificate, because that is the one whose private key signs the handshake. Every other certificate the client sends along is just data the client chose to include.

LXD's logic walked through every certificate the peer presented and compared each one against the trust store. If any of them matched, the client was in. So an attacker generates a throwaway key pair and certificate of their own, staples a trusted client's public certificate behind it in the chain, completes the handshake with their own key, and gets treated as the trusted client. Canonical's advisory put it plainly, noting that "only the leaf certificate proves ownership of the signing key," yet the code compared all of the peer certificates against the trust store.

The flaw was reported by the Incus project, the community fork of LXD, and credited to project lead Stéphane Graber. Incus published its own advisory, GHSA-xg75-xf37-cph9, on October 29 with a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. That is network reachable, low complexity, no privileges, no user interaction, and a scope change with full impact on confidentiality, integrity and availability. The Incus write-up also notes the issue has existed since the initial release of the code, which means this logic has been sitting in production for years. In Incus the same weakness let attackers reach cluster-internal endpoints, read or modify trust store entries, interfere with the host-to-VM agent connection, and feed attacker-chosen certificates into authorization scriptlets. The classification lands under CWE-287 for improper authentication and CWE-295 for improper certificate validation, which is about as on the nose as CWE mappings get.

Here is the part that should make administrators uncomfortable. Public certificates are not secrets. They are designed to be shared. They show up in cluster join flows, in configuration management repositories, in support bundles, in screenshots attached to forum posts, and in the trust store of every peer in the cluster. Treating a public certificate as a credential turns a whole category of harmless artifacts into keys to the kingdom.

Affected Versions and Fixes

Canonical shipped fixes across every supported LXD track. LXD 6.10.1 is the fixed release on the 6/stable channel, 5.21.9 covers 5.21/stable, 5.0.11 covers 5.0/stable, and 4.0.15 covers the long-lived 4.0/stable channel. Every release on those tracks before the fixed version is vulnerable. MicroCloud users need 3.4.1 on the 3/stable channel or 2.1.5 on 2/stable. Incus users should move to 7.6.0, which fixes this issue along with 17 other security problems the project disclosed in the same release.

Ubuntu's archive packages are listed as not affected or not shipped, so the snaps are what matter here. For most people that means running sudo snap refresh lxd and sudo snap refresh microcloud on every node. There is a wrinkle worth knowing about. Canonical noted that "all LXD point releases are currently in progressive roll out from candidate to stable," which means a refresh on one machine might not pull the same build as a refresh on its neighbor right away. Run snap list after refreshing and confirm the version number on every host rather than trusting that the command did what you expected. Snaps that are held or pinned to a specific revision will also sit quietly on the vulnerable build until somebody notices.

Who Is Actually Exposed

Before anyone panics about every Ubuntu laptop on the planet, some context. A standalone LXD install does not expose the HTTPS API by default. Out of the box it listens only on a local Unix socket, and the network listener only comes up when an administrator sets core.https_address. If you installed LXD to run a few containers on a dev box and never touched that setting, the remote attack path is not open.

Clustered deployments are a different story. LXD clusters need that HTTPS listener to talk to each other, and remote management with the lxc client depends on it too. MicroCloud, which is Canonical's packaged way to stand up LXD, MicroCeph and MicroOVN together as a small private cloud, is built around exactly the networked, multi-node setup this bug punishes. Canonical specifically called out that an attacker who can capture a member's public certificate as it joins a MicroCloud cluster can later authenticate as that member. Given that cluster members typically hold some of the most privileged identities in the environment, that is not a small thing.

The practical attacker profile looks like somebody who already has a foothold on the management network, or who finds an LXD API exposed to the internet, and who can scrape a trusted certificate from somewhere. That last part is easier than it sounds. Internet scanners already index exposed LXD endpoints, and anyone who has done incident response knows how often certificates end up in places they were never meant to be. Once inside, an attacker with an administrative identity can launch privileged containers, attach host devices, mount host paths into instances, and generally do everything that turns container management access into host root.

Exploitation Status

The good news, for now, is that nobody has reported exploitation in the wild. The CVE record carries a CISA assessment dated October 30 stating the flaw is not known to be exploited, it is not on the Known Exploited Vulnerabilities catalog, and no public exploit has been released. That status will not age well. The root cause is described in detail in two public advisories, the fix diffs are sitting in public repositories, and the technique needs nothing more than a few lines of code to build a custom certificate chain. Anyone who has written a TLS client in Go or Python could turn this into a working tool over a long lunch. Assume a proof of concept shows up soon and plan accordingly.

What To Do Right Now

Patching is the only real fix. Canonical offers no configuration workaround for LXD, and the Incus project says the same thing about its codebase. Until every node is updated, the one meaningful mitigation is limiting who can reach the HTTPS listener. Firewall the LXD API port, which defaults to 8443, so that only cluster peers and specific management hosts can connect. If a node has core.https_address bound to all interfaces and nobody remembers why, now is a great time to bind it to a management interface or turn it off entirely.

After patching, treat the trust store as potentially tainted for any cluster whose API was reachable from untrusted networks. Run lxc config trust list on each cluster and look for entries nobody recognizes, since an attacker impersonating an administrator could have quietly added their own certificate as a persistent backdoor that will survive the patch. Review the instance list for unexpected containers or VMs, particularly anything with security.privileged set to true, raw.lxc overrides, or disk devices mapping host paths. LXD's operation and lifecycle event logs, available through lxc monitor and forwarded to Loki if you have that configured, are the place to look for API calls coming from unexpected source addresses.

On the detection side, network teams can watch for TLS connections to port 8443 from hosts outside the expected cluster and management ranges. Connections where the client presents an unusually long certificate chain are also worth a second look, since legitimate LXD clients normally send a single self-signed certificate. If you rotate anything after this, rotate the client certificates of your most privileged identities and remove the old ones from the trust store, so that any copies floating around in old repositories become worthless.

The broader lesson is one the industry keeps relearning. Certificate chain handling is hard, and "we compare against the trust store" is not the same as "we verified the client proved possession of the key." If your own tooling does mutual TLS with custom verification logic, this is a good excuse to go read that code with fresh eyes.

MSP Angle

Plenty of MSPs and their clients have quietly adopted LXD and MicroCloud as a lighter alternative to VMware since the Broadcom licensing shakeup, and many of those deployments were built fast with API listeners wide open on flat networks. Offer a quick exposure review that covers patch verification, a trust store audit and network segmentation for the management plane, then use the findings to start a conversation about ongoing vulnerability management and external attack surface monitoring for the rest of their virtualization stack.