LXD certificate flaw enables trusted-client impersonation
A critical LXD certificate flaw allows an attacker to impersonate a trusted client without possessing that client’s private key, the secret used to prove its identity. The issue affects Canonical’s LXD and MicroCloud products and could expose a cluster and its virtual machines, which are software-based computers running inside a physical host. Canonical warned that impersonating a privileged account could give the attacker root access, meaning full administrative control of the host machine.
The vulnerability is tracked as CVE-2026-112816 and has the maximum CVSS score of 10.0. CVSS, or Common Vulnerability Scoring System, is a standard scale for rating the severity of security flaws. Canonical has released corrected versions of LXD and MicroCloud, although administrators need to verify that their installed version has actually received the update.
LXD and MicroCloud allow remote clients to connect through an HTTPS API, an encrypted network interface that software uses to exchange instructions and data. Authentication is handled through mutual TLS, a connection in which both the server and the connecting client use digital certificates to establish their identities. A server considers a client trusted when that client’s certificate appears in its trust store, the list of identities it has been configured to accept.
The flaw concerned how the server examined the certificate chain sent during a connection. The server compared every certificate supplied by the client with entries in its trust store. However, the TLS connection only demonstrates that the connecting client possesses the private key belonging to the first certificate in that chain, known as the leaf certificate. Any additional certificates attached behind it are selected by the connecting client and are not covered by that proof of ownership.
An attacker could therefore connect using a certificate and private key under the attacker’s control, then append the public certificate of a legitimate trusted client. Public certificates are not secret. Because the vulnerable server checked all certificates in the submitted chain, it could find the trusted certificate and accept the attacker as that client, even though the attacker did not possess the trusted client’s private key.
Exploitation requires two conditions. The attacker must be able to reach the target’s HTTPS API over the network and must have the public certificate of a client that the server already trusts. A standalone LXD installation does not expose its API to the network by default. It listens only through a local socket, a connection available on the same machine, unless an administrator enables network access with the core.https_address setting.
MicroCloud has an additional exposure because it combines several LXD machines into a cluster. Canonical said an attacker who captures a member’s public certificate while that machine is joining the cluster could later authenticate as the member. Successful impersonation would give the attacker whatever cluster and virtual-machine permissions had been assigned to that identity.
The CVE record identifies LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected before their respective corrected releases. Canonical lists LXD 6.10.1 in the 6/stable snap channel, 5.21.9 in 5.21/stable, 5.0.11 in 5.0/stable and 4.0.15 in 4.0/stable as fixed. For MicroCloud, the corrected versions are 3.4.1 in 3/stable and 2.1.5 in 2/stable. A snap is the packaged application format through which these releases are distributed.
The Incus project, which began as a community fork of LXD, originally reported the underlying problem. Canonical subsequently confirmed that LXD was also vulnerable. Incus corrected the same flaw in version 7.6.0, alongside 17 other security issues. Ubuntu’s archive packages for LXD are listed as either not affected or not shipped, so the relevant corrected LXD releases are the snap packages.
There is no public indication that CVE-2026-112816 has been exploited. A U.S. Cybersecurity and Infrastructure Security Agency assessment dated October 30 says the flaw is not known to have been used in attacks. It is not included in the agency’s Known Exploited Vulnerabilities list, and no working public exploit has been released.
Administrators should update snap installations by running sudo snap refresh lxd and sudo snap refresh microcloud. At the time of Canonical’s advisory, the corrected LXD point releases were still moving from the candidate channel into stable. Administrators should therefore inspect the installed version after refreshing instead of assuming the patched release was delivered.
Canonical provided no temporary LXD workaround. Restricting who can reach the HTTPS API can reduce exposure while the update is pending, but it does not correct the certificate-validation error. The Incus project likewise said there was no configuration-based fix and advised limiting network access to the listener until systems could be updated. Incus users should install version 7.6.0.
Organisations that need support securing the surrounding IT environment can use AEU-I for security-first IT, infrastructure and consulting. The priority for affected deployments remains installing the corrected release, confirming its version and keeping the management API inaccessible to untrusted networks.