A critical flaw in Canonical’s LXD and MicroCloud let an attacker log in as a trusted client without holding that client’s private key. To do it, the attacker had to reach their HTTPS API over the network and have the trusted client’s public certificate.
Once in, the attacker would act as that client, with access to the cluster and its virtual machines. If the impersonated account is privileged, the attacker could gain “root access to the host machine,” Canonical said.
The flaw, tracked as CVE-2026-112816, carries a maximum CVSS score of 10.0, and Canonical has released fixed versions of both products.
How the Flaw Works
LXD and MicroCloud let remote clients access their APIs over mutual TLS, a setup in which the client presents a certificate to prove who it is. A client is trusted when its certificate is in the server’s trust store, the list of identities the server will accept.
The flaw was in how the server checked that certificate. It compared every certificate the client sent against the trust store, but a TLS connection only proves the client owns the private key for the first certificate in the chain, the leaf. The rest of the chain is whatever the client chose to attach.
So an attacker could take a trusted client’s public certificate, which is not secret, attach it to the chain behind their own, and the server would accept them as that client.
Who Is Affected
Using the flaw takes two things: network access to the HTTPS API, and the public certificate of a client the server already trusts.
A standalone LXD server does not expose that API by default. It listens only on a local socket unless an administrator turns on the network API with the core.https_address setting.
MicroCloud, which ties several machines running LXD into one cluster, has a specific weak point. 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 the fixed release that follows. Canonical lists these fixed snap versions:
| Product | Snap channel | Fixed version |
|---|---|---|
| LXD | 6/stable | 6.10.1 |
| LXD | 5.21/stable | 5.21.9 |
| LXD | 5.0/stable | 5.0.11 |
| LXD | 4.0/stable | 4.0.15 |
| MicroCloud | 3/stable | 3.4.1 |
| MicroCloud | 2/stable | 2.1.5 |
The bug did not start at Canonical. The Incus project, which began as a community fork of LXD, reported it, and Canonical confirmed it affected LXD as well. Incus fixed the same flaw 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.
There is no public sign the flaw has been used in an attack. The CVE record carries a U.S. 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.
What to Do
Update LXD and MicroCloud to the fixed versions. On a snap install, run sudo snap refresh lxd and sudo snap refresh microcloud.
Canonical said the fixed LXD point releases were still rolling out from the candidate channel to stable at the time of its advisory, so check the version you actually have after the refresh rather than assume the fix arrived.
Canonical’s advisory gives no temporary workaround for LXD. Because the attack requires network access to the API, limiting who can reach it reduces risk until you update. The Incus project, reporting the same flaw, said there is no configuration fix and that the only step is to restrict network access to the listener.
Incus users should move to 7.6.0, which fixed this flaw along with 17 other security issues.
