Canonical has released fixed versions of LXD and MicroCloud after a critical flaw allowed an attacker to log in as a trusted client without holding that client's private key. The vulnerability, tracked as CVE-2026-112816, carries a maximum CVSS score of 10.0, and The Hacker News reported the details on November 1, 2026, citing Canonical's advisory.
LXD is Canonical's system container and virtual machine manager, widely used to run dense workloads on Linux servers. MicroCloud builds on LXD to tie several machines into a single cluster. Both products let remote clients reach their HTTPS APIs over mutual TLS, in which a client presents a certificate to prove its identity and is trusted when that certificate sits in the server's trust store.
The bug was in how the server checked that certificate. A TLS connection proves the client owns the private key only for the first certificate in the chain, the leaf. According to the reporting, the server compared every certificate the client sent against its trust store, including certificates further up the chain that the client could attach freely. An attacker could therefore take a trusted client's public certificate, which is not secret, attach it behind their own certificate, and be accepted as that client.
Once accepted, the attacker acts with that client's access to the cluster and its virtual machines. Canonical said that if the impersonated account is privileged, the attacker could gain root access to the host machine. Exploitation requires two things: network access to the HTTPS API, and the public certificate of a client the server already trusts.
Exposure differs by deployment. A standalone LXD server does not expose that API by default; it listens only on a local socket unless an administrator enables the network API through the core.https_address setting. MicroCloud clusters face a sharper risk, because Canonical said an attacker who can capture a member's public certificate as it joins the cluster can then log in as that member.
The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before its fixed release. Canonical listed fixed snap versions of 6.10.1 for the 6/stable channel, 5.21.9 for 5.21/stable, 5.0.11 for 5.0/stable and 4.0.15 for 4.0/stable, plus MicroCloud 3.4.1 on 3/stable and 2.1.5 on 2/stable. Ubuntu's own archive packages of LXD were listed as not affected or not shipped, so the fixed releases are the snaps.
The flaw was first reported by the Incus project, the community fork of LXD, which fixed the same issue in version 7.6.0 alongside 17 other security issues. There is no public sign of exploitation so far: the CVE record carries a United States CISA assessment dated October 30 that the flaw is not known to have been exploited, it is not on CISA's Known Exploited Vulnerabilities list, and no working exploit has been published.
Administrators should update promptly with sudo snap refresh lxd and sudo snap refresh microcloud, then verify the version actually installed, because Canonical said the fixed LXD point releases were still rolling out from the candidate channel to stable when its advisory was published. There is no temporary workaround or configuration fix; until the update lands, the only mitigation is to restrict who can reach the HTTPS API over the network. For teams running virtualization clusters, this is a patch-first item: a maximum-severity authentication bypass leaves little margin for delay once a trusted certificate can be observed.