Canonical patches a 10-out-of-10 LXD flaw that let strangers walk in as trusted admins
A certificate-checking mistake in LXD and MicroCloud let anyone who could reach the API log in as someone else. Canonical shipped fixes on October 28.
Key points
- Canonical patched CVE-2026-112816 on October 28, 2026, a flaw rated critical that let an attacker log in to the LXD or MicroCloud management interface as any trusted user whose public certificate they could obtain.
- The bug sits in how LXD checked TLS client certificates: it trusted any certificate anywhere in the chain, instead of only the one proving the client owned the matching private key.
- Fixed versions are LXD 4.0.15, 5.0.11, 5.21.9 and 6.10.1; anything older on those branches is vulnerable.
- The flaw was reported to Canonical by the Incus project, a community fork of LXD, after it was found there first.
- An attacker needed network reach to the HTTPS API and a copy of a trusted client's public certificate, which is not itself a secret.
Canonical, the company behind Ubuntu Linux, has fixed a serious bug in two of its server products that let an outsider log in as a trusted administrator without stealing any password or key.
The products are LXD, a system for running lots of virtual machines and Linux containers on one host, and MicroCloud, a packaged way of clustering several LXD machines together. Both are widely used by hosting providers and in-house IT teams who want something lighter than a full cloud platform.
The advisory, posted on Canonical's Ubuntu discourse on October 28, 2026, is tracked as CVE-2026-112816. The Hacker News reported it carried a maximum CVSS severity score of 10.0, the highest a flaw can get.
How did the bug actually work?
LXD lets trusted clients connect using mutual TLS, where both sides prove who they are with a cryptographic certificate. The server is meant to check that the client holds the private key for the one certificate it recognises.
LXD checked the whole chain of certificates the client sent, and accepted a match on any of them. Only the final certificate, the leaf, actually proves the client owns the matching private key. An attacker could stuff a trusted administrator's public certificate (which is not secret, it is handed out openly) into the middle of their own chain, present their own leaf certificate, and LXD would wave them through as that administrator.
In MicroCloud, the same trick worked against clustering. An attacker who could grab the public certificate of a machine joining a cluster could then log in as that machine.
Who is affected and what should they do?
Anyone running LXD 4.0.14, 5.0.10, 5.21.8 or 6.9, or any older release on those branches, with the HTTPS API reachable. The fix is to update to 4.0.15, 5.0.11, 5.21.9 or 6.10.1. MicroCloud users get the fix through the same channel.
| Branch | Vulnerable up to | Patched version |
|---|---|---|
| 4.0 LTS | 4.0.14 | 4.0.15 |
| 5.0 LTS | 5.0.10 | 5.0.11 |
| 5.21 | 5.21.8 | 5.21.9 |
| 6.x | 6.9 | 6.10.1 |
If the LXD API is only reachable on a local socket, not over the network, the risk is much lower. Teams that expose the HTTPS listener to a management network, or worse to the public internet, should treat this as urgent. Rotating client certificates after patching is sensible, because any public certificate an attacker already collected is still usable against unpatched hosts.
Does this affect ordinary people?
Not directly. There is no customer data leak here, no password to reset. The people who need to act are system administrators running LXD or MicroCloud clusters.
That said, the virtual machines sitting inside those clusters are often someone's website, someone's shop, someone's medical records system. A full takeover of the cluster means a full takeover of everything running on it. The practical risk to the public depends entirely on whose clusters got patched quickly and whose did not.
One detail worth sitting with: the bug was found first in Incus, the community fork that split from LXD in 2023, and reported across. Shared heritage means shared bugs, and in this case the fork's maintainers did the open-source world a favour.
