Canonical has fixed a maximum-severity flaw in LXD and MicroCloud that lets an attacker log in as a trusted client without holding that client’s private key. The vulnerability, tracked as CVE-2026-112816, carries a CVSS score of 10.0, and the fix is a straightforward update to the patched snap releases. If you run LXD with its network API exposed, or you run a MicroCloud cluster, patch now and then confirm the version you actually have installed.
The short version is this: the server checked every certificate in the chain a client presented, but a TLS connection only proves ownership of the private key for the first certificate in that chain. An attacker who knew a trusted client’s public certificate, which is not secret, could attach it behind their own certificate and be accepted as that client. From there, a privileged impersonated account could mean full control of the cluster and its virtual machines, and Canonical says it could mean root access to the host machine.
What happened
Canonical published its security advisory on October 28, 2026, after the Incus project reported the problem and Canonical confirmed it affected LXD as well. Incus began as a community fork of LXD, and it fixed the same flaw in version 7.6.0. The CVE record was published on October 30, 2026.
The flaw sits in how LXD validates certificates on its HTTPS listener. LXD and MicroCloud use mutual TLS for remote API access. In that setup, the client presents a certificate to prove who it is, and the server accepts the client only if that certificate is in its trust store. The bug was that the server compared every certificate the client sent against the trust store, instead of checking only the certificate the client actually proved ownership of.
That distinction matters because only the first certificate in a TLS chain, the leaf, is backed by a private key proof during the handshake. The rest of the chain is simply what the client chose to attach. So an attacker could put their own certificate first, attach a trusted client’s public certificate behind it, and pass the check. Public certificates are not secrets, so obtaining one is not the hard part. Reaching the API over the network is the real precondition.
Who is affected
Two things have to be true for an attack to work: the attacker needs network access to the LXD HTTPS API, and they need 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. That limits exposure for many single-server setups, but it does not help a server where remote API access was deliberately enabled, or a cluster where it is part of normal operation.
MicroCloud has a specific weak point. MicroCloud ties several machines running LXD into one cluster, and Canonical says an attacker who can capture a member’s public certificate as it joins the cluster can then log in as that member. In a cluster, the impersonated account may carry exactly the privileges an attacker wants.
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. Ubuntu’s own archive packages of LXD are listed as not affected or not shipped, so the fixed releases to look for are the snaps.
Fixed versions and how to patch
Canonical released fixed snap versions on October 29, 2026. Update to the fixed release for the branch you run:
- 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
- Incus: 7.6.0
On a snap install, run sudo snap refresh lxd and sudo snap refresh microcloud. Then check the version you actually have, because Canonical said the fixed LXD point releases were still rolling out progressively from the candidate channel to stable when its advisory was published. Do not assume the refresh delivered the fix. Run lxd –version and compare it against the fixed version for your branch, and repeat the refresh if you are still on an affected release.
There is no configuration workaround that fixes this properly. 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, through firewall rules or network segmentation, but that is a holding measure, not a fix. The Incus project said the same thing in its own terms: there is no configuration fix, and the only step short of updating is to restrict network access to the listener.
Is this flaw being exploited?
As of November 1, 2026, there is no public sign that the flaw has been used in an attack. The CVE record carries a US CISA assessment dated October 30, 2026, stating 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.
That is reassuring, but it is not a reason to wait. A CVSS 10.0 authentication bypass with a clear mechanism and a public advisory is exactly the kind of flaw that attracts attention quickly once the details are out. The patch is a point release, the commands are simple, and the check afterward takes seconds. There is no benefit in leaving a cluster exposed while the details circulate.
It is also worth checking your trust store while you are there. If clients that no longer need access are still trusted, remove them. Every trusted certificate is a potential impersonation target if an attacker can reach the API, so a stale entry is not harmless clutter. The same review applies to cluster members that have been retired or rebuilt.
Why this flaw is easy to misunderstand
It is tempting to read this as a private key leak, but it is not. No private key is stolen or exposed here. The flaw is a validation error: the server trusted a certificate it had never verified ownership of, simply because that certificate appeared somewhere in the chain the client presented.
That is also why the fix matters more than any certificate rotation on its own. Rotating a trusted client’s certificate after patching is good hygiene if you suspect exposure, but rotation alone on an unpatched server would not close the hole, because the attacker could simply attach the new public certificate instead. Patch first, then review trust and certificates as a second step.
For context, this is a different kind of risk from the guest-to-host escapes that sometimes make headlines in virtualization. A flaw like the KVM zero-day VM escape breaks out of a virtual machine, while this LXD flaw breaks into the management layer that controls the machines in the first place. Both end in a bad place for the host, but they need different fixes and different checks. Similarly, the Tailworm flaws in Tailscale SSH were a reminder to lock down remote access paths even before a patch exists. Here a patch does exist, which makes delay harder to justify.
The pattern is familiar from other critical platform flaws. When a CVSS 10.0 GitLab flaw appeared in October, the advice was the same: patch the platform, verify the version, and do not rely on network position alone. The same discipline applies here, and it applies to any internet-facing management service, as the WordPress 7.1.4 security update showed for website owners the same week.
What to do right now
- Check whether your LXD API is exposed on the network, and whether you run MicroCloud. If neither applies, you are in a much lower risk position, but still update on your normal cycle.
- Update LXD and MicroCloud to the fixed versions listed above with sudo snap refresh lxd and sudo snap refresh microcloud.
- Verify with lxd –version. If the version has not moved to the fixed release, the progressive rollout may not have reached you yet, so try again and check again.
- Restrict network access to the API to only the hosts and networks that genuinely need it, until the patch is confirmed in place.
- Review the trust store and remove clients and cluster members that no longer need access.
- If you run Incus instead of LXD, move to 7.6.0, which fixed this flaw along with 17 other security issues.
Frequently asked questions
What is CVE-2026-112816?
CVE-2026-112816 is an improper certificate validation flaw in the HTTPS listener in Canonical LXD, which also affects MicroCloud. An unauthenticated attacker with network access to the API could authenticate as any trusted TLS client for which they have the public certificate, gaining full access to the cluster and the virtual machines it manages.
Do I need the trusted client’s private key to exploit it?
No. That is the point of the flaw. The attacker only needs the trusted client’s public certificate, which is not secret, and network access to the HTTPS API. The server incorrectly accepted certificates further down the chain that the client had not proven ownership of.
Am I affected if my LXD server is standalone?
Probably not directly, if you never enabled the network API. A standalone LXD server listens only on a local socket by default. You are at risk if you turned on remote API access with core.https_address, or if you run MicroCloud, where cluster membership changes the picture.
Which versions fix CVE-2026-112816?
LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, MicroCloud 3.4.1 and 2.1.5, and Incus 7.6.0. Update to the fixed release for your branch, then verify the installed version, because the LXD point releases were rolling out progressively from candidate to stable.
Has CVE-2026-112816 been exploited in the wild?
Not as far as public reporting shows. CISA’s assessment dated October 30, 2026, says the flaw is not known to have been exploited, it is not on the Known Exploited Vulnerabilities list, and no working exploit has been published. Patch anyway, because the mechanism is public and the severity is maximum.
Is there a workaround if I cannot update immediately?
There is no configuration workaround that fixes the flaw. The only risk reduction short of patching is to restrict network access to the LXD API so that only trusted hosts and networks can reach it, and to treat that as a temporary measure while you get the update installed and verified.