Canonical says CVE-2026-112816 lets an attacker log in to the LXD or MicroCloud API as a trusted client without its private key, and possibly reach root on the host. Fixed in LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15 and MicroCloud 3.4.1 and 2.1.5. There is no workaround.
If your team runs LXD or MicroCloud with the API reachable over the network, run sudo snap refresh lxd and sudo snap refresh microcloud today, then check the installed version. Canonical rates the bug CVSS 10.0, says an attacker can log in as one of your trusted clients without that client’s private key, and offers no workaround.
What Canonical disclosed
Canonical’s security advisory, posted October 28, covers CVE-2026-112816, an authentication bypass in how LXD and MicroCloud check client certificates. Both use mutual TLS: a client proves who it is with a certificate the server already trusts. The server checked every certificate the client sent against its trust list, while the client only had to prove it held the private key for one of them. An attacker with a trusted client’s public certificate could present it and be treated as that client.
According to Canonical, “depending on the privilege of the victim user, the attacker may gain root access to the host machine.” In MicroCloud, an attacker who captures a member’s public certificate while it joins the cluster can then log in as that member.
The Hacker News reports that the Incus project, the community fork of LXD, found and reported the flaw and fixed it in Incus 7.6.0. CISA’s assessment lists it as not known to be exploited.
Fixed 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 |
Canonical said the LXD point releases were rolling out progressively from candidate to stable, so a refresh may not land the fix on every machine at once. Run lxd --version or snap list lxd after refreshing and compare against the table.
Who needs to act today
The attacker needs network access to the LXD HTTPS API. A standalone LXD server does not listen on the network by default; it only does once someone sets core.https_address, according to The Hacker News. Clusters and MicroCloud deployments do expose it between members. So the urgent cases are clusters, MicroCloud, and any LXD host where the API was opened up for remote management or automation.
Until every host shows a fixed version, restrict who can reach the API port with a firewall or VPN. The Incus project says no configuration change fixes the flaw, so network restriction is the only stopgap.
A stolen public certificate is now enough
Teams usually treat a client’s public certificate as harmless to share. This bug turns it into a login. If your LXD client certificates were ever copied into CI configs, wikis or shared repos, assume they are known, patch first, and then consider rotating trusted client certificates once you are on a fixed release.
Reported by The Hacker News, with Canonical’s advisory as the primary source.