Maximum-Severity Flaw in Canonical's LXD and MicroCloud Lets Attackers Pose as Trusted Clients

Canonical has fixed a critical flaw, tracked as CVE-2026-112816 and rated 10.0 on the CVSS scale, in its LXD and MicroCloud products. An attacker who can reach the HTTPS API over the network and holds a trusted client's public certificate could log in as that client without its private key. They would then have access to the cluster and its virtual machines. If the impersonated account is privileged, Canonical said the attacker could gain "root access to the host machine."

The problem lay in how the server checked certificates. A TLS connection only proves the client owns the private key for the first certificate in the chain. The server, however, compared every certificate the client sent against its list of trusted identities. Because a public certificate is not secret, an attacker could attach a trusted client's certificate behind their own, and the server would accept them as that client. In MicroCloud, an attacker who captures a member's public certificate as it joins the cluster could then log in as that member.

A standalone LXD server does not expose this API by default, and listens only on a local socket unless an administrator enables the network API. The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before its fixed release. The Incus project, a community fork of LXD, reported the bug and fixed it in version 7.6.0. Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the fixed releases are the snaps.