Canonical has fixed CVE-2026-112816, a critical authentication bypass in LXD and MicroCloud that lets an attacker pose as a trusted client using only that client's public certificate. Patch any LXD server with a reachable HTTPS API first.
What happened
Canonical published its advisory on October 28, 2026, with fixed snaps dated October 29. The issue came to Canonical from the Incus project, which fixed the same flaw in Incus 7.6.0, and Canonical confirmed that it also affects LXD.
LXD's remote API uses mutual TLS, and its check accepted a trust store match on any certificate in the client's chain. The handshake only shows the client holds the leaf's key. An attacker could therefore present their own certificate as the leaf, attach a trusted client's public certificate as an intermediate, and authenticate as that client.
MicroCloud has its own route, per Canonical: capture a joining member's public TLS certificate and log in as that member. Canonical also warns of root on the host if the impersonated user is privileged enough.
| 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 |
Severity depends on where you look. Canonical's advisory says "critical" without giving a score. The CVE record, with Canonical as CNA, carries a CVSS v4.0 score of 10.0, while Ubuntu's CVE tracker lists a priority of Medium. The Hacker News also reports no public sign of exploitation and no listing in CISA's KEV catalog.
Why it matters
This is a machine identity failure, not a cryptography failure. A public certificate is not a secret, so its presence in a handshake proves nothing unless the sender also proves control of the matching private key. A trust store that matches on any certificate in the chain turns a public identifier into a working credential.
Canonical's CVE description spells out the LXD impact, saying the flaw:
"allows an unauthenticated attacker to authenticate as any trusted client and gain full access to the cluster and managed virtual machines"
The Incus advisory adds detail on that project. A client needs no earlier foothold to get a server certificate, it says, because each TLS handshake hands one over. Adding that certificate to the chain opens the database gateway, and on a cluster, a fellow member's certificate opens internal cluster access. Canonical's post doesn't repeat those specifics, and the LXD GitHub advisory it links returned a 404 when this was written. Treat those Incus details as a reason for caution, not confirmed LXD behavior.
Standalone LXD has a narrower default. Canonical's documentation says a server is reachable only through a local Unix socket until core.https_address is set. The web UI and remote management both require that exposure, so check rather than assume.
What to check in your environment
- Find exposed listeners. Record every LXD host with
core.https_addressset, and check whether it's reachable from user networks, other tenants or the internet. - Apply the update. Canonical's commands are
sudo snap refresh lxdandsudo snap refresh microcloud. Point releases were rolling out from candidate to stable, so confirm the installed version against the table. - Inventory snaps, not apt. Canonical lists no affected ranges, and Ubuntu's tracker names LXD 4.0.14, 5.0.10, 5.21.8 and 6.9. It shows the archive package as not affected or not in release, so focus on snaps. Treat older versions and other channels as exposed until shown otherwise.
- Restrict the API until patched. Canonical documents no workaround. The Hacker News notes that tighter network limits on the API lower the risk, so allow only known management hosts.
- Don't count on PKI mode. Neither advisory says CA-signed client certificates prevent this, so patch on the same schedule.
- Protect MicroCloud joins. Hold planned member additions until the fixed snaps are in place, and review recent joins that crossed untrusted network segments.
- Review the trust store and access logs. Canonical publishes no indicators. Look for trust store entries nobody can account for, and compare listener traffic in firewall or flow logs against your management hosts.
- Cover Incus separately. Its advisory lists versions below 7.6.0 as affected and says no configuration workaround exists beyond restricting network access. If you run Incus 7.0 LTS, confirm fix status with the project.
References
- Canonical: Critical vulnerability found in Canonical LXD and MicroCloud
- CVE record: CVE-2026-112816
- Ubuntu: CVE-2026-112816
- The Hacker News: Critical LXD and MicroCloud flaw
- Incus: GHSA-xg75-xf37-cph9, unverified client certificate chains
- LXD documentation: Exposing LXD to the network
- LXD documentation: Authentication