CVSS 10.0: LXD and MicroCloud Bug Let Attackers Impersonate Trusted Clients With No Private Key Required
A maximum-severity vulnerability in Canonical's LXD and MicroCloud gave attackers a way to authenticate as a trusted client without ever possessing that client's private key. The flaw scores a perfect 10.0 on the CVSS scale, which should tell you everything you need to know about how serious Canonical considered it.
Tracked as CVE-2026-112816, the bug has been patched. Fixed versions of both products are available now.
The core problem
LXD and MicroCloud expose remote APIs over mutual TLS. The whole point of mutual TLS is that the client proves its identity by presenting a certificate and demonstrating it holds the matching private key. The server checks the certificate against a trust store and, if it finds a match, lets the client in.
Except the server wasn't checking that correctly.
TLS only guarantees the client controls the private key for the leaf certificate, the first one in the chain. Any additional certificates further along the chain are just whatever the client decided to include. Nobody verifies ownership of those.
The server was checking every certificate in the chain against its trust store. So an attacker could grab a trusted client's public certificate, which is not secret and doesn't need to be stolen in any dramatic sense, attach it somewhere in their own chain, and the server would happily wave them through as that trusted client.
If the impersonated client had elevated privileges, the attacker ends up with root access to the host. Canonical said so explicitly.
Who's actually at risk
Two things are needed: network access to the HTTPS API, and a trusted client's public certificate.
A default standalone LXD installation doesn't expose the network API at all. It listens on a local socket unless an administrator explicitly enables remote access via the `core.https_address` setting. So plenty of LXD deployments were never reachable in the first place.
MicroCloud is a different story. It clusters multiple LXD machines together, and Canonical specifically flagged a weak point during the join process. An attacker who can capture a member's public certificate as it joins the cluster can then use that certificate to impersonate that member.
Affected versions and fixes
The CVE record covers LXD versions 4.0.14, 5.0.10, 5.21.8, and 6.9. The fixed snap releases are:
- 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
Ubuntu archive packages of LXD are listed as unaffected or not shipped, so the relevant fixes are in the snaps.
This wasn't Canonical's discovery. The Incus project, a community fork of LXD, found the bug first and fixed it in Incus 7.6.0 alongside 17 other security issues. Canonical then confirmed LXD was affected by the same flaw.
CISA assessed the vulnerability on October 30 and found no evidence of active exploitation. It's not on their Known Exploited Vulnerabilities list, and no working public exploit has surfaced.
What to do
Update. Run `sudo snap refresh lxd` and `sudo snap refresh microcloud`. Then check the installed version manually rather than assuming the update landed, because Canonical noted the fixed releases were still rolling out from the candidate channel to stable at the time of their advisory.
There's no configuration workaround in Canonical's guidance. Restricting network access to the API will reduce your exposure in the meantime, but it's not a fix. The Incus project made the same point: limit access to the listener and update, there's nothing else.
Incus users should be on 7.6.0 already.