Canonical has fixed a critical authentication flaw in LXD, its system container and virtual machine manager, and in MicroCloud, the clustering layer built on top of it. Tracked as CVE-2026-112816 and scored 10.0, the maximum, under CVSS 4.0, the bug let an attacker who could reach the LXD HTTPS API log in as a trusted client without ever holding that client's private key. The attacker did need that client's public certificate. According to Canonical's advisory, that access can be enough to get root on the host.
Fixed snap packages went out on October 29. As of the CVE record's October 30 assessment there was no known exploitation, and no public exploit has been reported. Even so, any team running LXD or MicroCloud with the network API turned on should treat this as a patch-today item.
The Short Version
LXD trusts remote clients through mutual TLS. Each client presents a certificate, and the server checks it against a list of client certificates it already trusts. The flaw was in how that check worked. Instead of looking only at the certificate the client had proved it owns, LXD compared every certificate in the chain the client sent against its trust store. An attacker could therefore build a chain with their own certificate as the leaf and tuck a legitimately trusted client's public certificate in as an "intermediate." LXD saw a trusted certificate somewhere in the bundle and let the connection in.
Public certificates are not secrets. That is why this bug is so serious: the one credential the attacker needs is one defenders usually don't bother to protect.
Why Only the Leaf Counts
Some background on how TLS client authentication works. When a client connects, it sends a certificate chain. The first certificate is the "leaf," which identifies the client. Any certificates after it are intermediates that link the leaf back to some authority. During the handshake the client also proves it holds the private key that matches the leaf. It proves nothing about the other certificates in the chain, and it can't, because it was never asked to.
Canonical's advisory states the problem directly: the remote API's mutual-TLS logic "compared all peer certificates sent by the client to known trust store entries," even though only the leaf certificate proves ownership of the signing key. Any certificate past the leaf is just data the client chose to include. Treating a match on one of those as proof of identity is the improper certificate validation that the record classifies as CWE-295. The CVE.org entry also maps it to CAPEC-475, the attack pattern for signature spoofing through improper validation.
What an Attacker Gets
The NVD entry says an unauthenticated attacker can authenticate as any trusted client and gain full access to the cluster and the managed virtual machines, using a crafted certificate chain. Canonical's advisory adds that, depending on the privilege of the impersonated user, the attacker may gain root access to the host machine.
MicroCloud has an extra twist. According to Canonical, an attacker who intercepts the public certificate of a joining cluster member can then authenticate as that member. Join traffic suddenly matters a lot more than it did before.
Who Is Actually Exposed
The main limiting factor is reachability. The Hacker News notes that exploiting the flaw takes two things: network access to the HTTPS API and the public certificate of a client the server already trusts. Standalone LXD does not expose its network 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 its own weak point in the join process described above.
The CVE record lists affected LXD releases in four maintenance tracks, 4.0.14, 5.0.10, 5.21.8 and 6.9.0, fixed in 4.0.15, 5.0.11, 5.21.9 and 6.10.1 respectively. The Hacker News reports that the LXD packages in the Ubuntu archive are listed as not affected or not shipped, so the fixed releases are the snaps.
The bug didn't start with Canonical's own research. The advisory says the Incus project, the community fork of LXD, referred it to Canonical, which then confirmed LXD was affected. Incus fixed the same flaw in version 7.6.0 along with 17 other security issues, per The Hacker News. Incus also says there is no configuration fix. The only interim step is restricting network access to the listener.
Exploitation Status
The Hacker News reports that the CVE record carries a CISA assessment dated October 30 saying the flaw is not known to have been exploited. It also reports that the flaw is not on CISA's Known Exploited Vulnerabilities catalog and that no working exploit has been published. NVD lists the entry as "Deferred" and shows the CVSS 4.0 score supplied by the CNA, [email protected]. None of that makes the bug less serious. The technique is simple to describe, and now that the advisory is public, a working attack doesn't take much imagination.
What It Means for Defenders
Find your exposure first. List every host running LXD or MicroCloud and check whether the HTTPS API is enabled, which on standalone LXD means core.https_address is set. Clustered and MicroCloud deployments need network reachability between members, so check those too. Hosts that only listen on the local socket are far less exposed, but they should still be patched.
Update to the fixed snaps. Canonical released these on October 29:
- LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, one for each maintenance track
- MicroCloud 3.4.1 on the 3/stable channel and 2.1.5 on 2/stable
Canonical's fix is to refresh the lxd and microcloud snaps. The advisory notes the LXD point releases were in progressive rollout from the candidate channel to stable, so check the installed version after refreshing rather than assuming the update landed. If a host still shows an older build, it hasn't picked up the fix yet.
Restrict the listener until you're patched. Canonical's advisory gives no temporary workaround, and Incus says there is no configuration fix. Because the attack requires network access to the API, firewall the LXD HTTPS port so that only known management hosts and cluster peers can reach it, and never expose it to the internet.
Review trust and activity. Since the attack reuses certificates that are already trusted, go through your list of trusted client identities, remove any that are stale or unused, and look at recent API activity for privileged actions you can't account for, such as new instances, changed devices, or configuration edits. MicroCloud operators should also think back to recent cluster joins that went over networks they don't control, since join-time certificates are what the MicroCloud variant of the attack targets.
Incus users: move to 7.6.0, which fixes this bug along with 17 other security issues.
For CMMC and compliance teams: a vendor-rated CVSS 10 authentication bypass on virtualization infrastructure belongs in your flaw-remediation records. Record the affected assets, the date each was patched, and any compensating network restrictions you put in place while waiting.
