Canonical Patches a CVSS 10.0 Flaw Letting Attackers Impersonate Trusted LXD, MicroCloud Clients

Canonical published a security advisory on 28 October 2026 disclosing a critical flaw in the mutual-TLS authentication used by LXD, its system container and virtual-machine manager, and MicroCloud, its clustering tool built on top of LXD. Tracked as CVE-2026-112816, the bug let an attacker who had only ever seen a victim's public certificate authenticate to the LXD or MicroCloud API as that victim — no private key required. Canonical shipped fixed packages the following day, 29 October 2026, for every LXD release branch it still supports.

According to Canonical's advisory on Ubuntu Discourse, the "remote API authentication logic for mutual TLS compared all peer certificates sent by the client to known trust store entries. However, only the leaf certificate proves ownership of the signing key." In practice, a client's public certificate is not secret — it is, by design, something the client hands to a server. The flawed code let an attacker tack a victim's public certificate onto the end of their own certificate chain and be granted that victim's identity, because the server checked every certificate in the chain against its trust store instead of checking only the one certificate the connecting party could actually prove it held the key for.

Canonical's advisory states the consequence directly: "An attacker may gain trust with the LXD or MicroCloud daemon by impersonating another user with only their public client certificate. Depending on the privilege of the victim user, the attacker may gain root access to the host machine." For a MicroCloud deployment, where instances cluster over the network using LXD's trust mechanism, an attacker who obtained a cluster member's public certificate could authenticate as that member during cluster onboarding and reach the cluster's management plane.

Where the bug came from

Canonical's advisory says the issue "was referred to us from the Incus project" — the community fork of LXD that continued development after the project split from Canonical. Incus published its own advisory for the same underlying bug, GHSA-xg75-xf37-cph9, crediting GitHub user stgraber (Incus project lead Stéphane Graber) with reporting it. Incus rates the flaw 10.0 on the CVSS v3.1 scale, the maximum possible score, and says it affected every Incus version before 7.6.0. The Hacker News, in its report of the disclosure, also cites a CVSS score of 10.0 for the Canonical-tracked CVE-2026-112816.

Who needs to patch

The fix landed across every branch Canonical still maintains: LXD 4.0.15, 5.0.11, 5.21.9 and 6.10.1, plus MicroCloud 2.1.5 and 3.4.1, all dated 29 October 2026 in Canonical's advisory. Users who installed LXD or MicroCloud as snap packages can update immediately by running sudo snap refresh lxd and sudo snap refresh microcloud. Incus users need version 7.6.0 or later. Because the flaw sits in the authentication layer itself rather than in a specific feature, Incus's advisory notes there is no configuration workaround short of restricting network access to the HTTPS API until the daemon is upgraded.

Why this matters beyond one project

LXD and MicroCloud are widely used to run system containers and lightweight virtual machines on Ubuntu and other Linux distributions, including in university computing clusters and research infrastructure where multiple users or research groups share a host through LXD's container isolation. A flaw that turns a non-secret public certificate into a usable credential undermines the basic assumption mutual TLS is supposed to provide: that only the holder of a private key can authenticate as its owner. Any system administering shared compute this way, including teaching labs and research clusters that give students or lab members their own LXD containers, should treat this as a software update to apply immediately rather than a routine patch to queue.

For engineers building or reviewing authentication systems, the specific mistake is instructive on its own: validating every certificate in a presented chain against a trust store, rather than validating that the connecting party holds the private key matching the one certificate actually used to establish the TLS session, is a distinction that is easy to miss in code review and easy to exploit once found. Canonical's advisory and Incus's independent write-up both describe the fix as tightening that check to the leaf certificate alone.