Canonical has patched CVE-2026-112816, a maximum-severity authentication bypass in LXD and MicroCloud that lets an attacker pose as a trusted client using only that client’s public certificate. The flaw carries a CVSS score of 10.0, and no exploitation has been reported.
How CVE-2026-112816 Bypasses LXD Mutual TLS Authentication
An attacker who can reach the LXD HTTPS API and holds a trusted client’s public certificate can authenticate as that client without possessing the private key. The cause is in the mutual-TLS check. LXD compared every certificate in the client’s presented chain against its trust store, even though only the leaf certificate proves the client holds the matching private key.
That logic lets an attacker present their own leaf certificate and attach a trusted public certificate as an intermediate behind it. The trust store finds a match, and the connection is accepted.
Cluster, VM and Root Access Through an Impersonated Privileged Account
The damage depends on whose certificate the attacker holds. If the impersonated account is privileged, the result can be full control of the cluster, its virtual machines and root access on the host. In MicroCloud, an attacker who captures the public certificate of a joining member can pose as that member.
Public certificates are not secrets in the way private keys are, which is why a flaw that accepts them alone as proof of identity scores at the top of the scale.
Standalone LXD Installs Do Not Expose the Network API by Default
The exposure is narrower than the score suggests for many deployments. Standalone LXD does not expose its network API by default and listens only on a local socket unless an administrator sets core.https_address. Clusters, MicroCloud deployments and hosts where the address was configured are the ones an attacker can reach over HTTPS.
Incus Project Reported the Bug and Fixed It in Version 7.6.0
The Incus project reported the vulnerability and fixed it in its own 7.6.0 release. Canonical then confirmed that LXD shared the same bug. Canonical released fixed snaps on October 29, and public write-ups followed on October 31 and November 1.
Fixed LXD and MicroCloud Versions and Rollout Status
Canonical’s fixes cover several release tracks: LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, plus MicroCloud 2.1.5 and 3.4.1. The MicroCloud builds are progressing as a rollout candidate toward the stable channel. Affected versions include LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 through 6.10.0, along with MicroCloud 2.x and 3.x.
The vulnerability is not listed in CISA’s Known Exploited Vulnerabilities catalog, and no in-the-wild activity has been reported. Canonical’s guidance is to refresh the lxd and microcloud snaps and to restrict access to the API.
The disclosure path shows how a flaw can cross project boundaries: the Incus project found the problem, and Canonical confirmed LXD was affected too. Patches for the older 4.0 and 5.0 branches mean operators who stay on long-running releases do not have to move to a newer series to close the hole.
The two environments differ in how an attacker would get an opening. On a standalone LXD host, the network API is off unless an administrator sets core.https_address, so most single-host installations are not reachable over HTTPS by default. MicroCloud is built around clustering, which means members exchange certificates when they join. That is the point at which the reported joining-member scenario applies: an attacker who captures a joining member’s public certificate can pose as that member.
Canonical’s four fixed LXD versions correspond to the four affected release lines, while MicroCloud receives separate builds for its 2.x and 3.x series. Operators can confirm their position by checking the installed snap version against the list of fixed releases.
