LXD, MicroCloud flaw CVE-2026-112816 lets clients be impersonated

Canonical has patched CVE-2026-112816, a maximum-severity flaw in the HTTPS listener of LXD and MicroCloud that lets an unauthenticated attacker authenticate as any trusted client and take full control of the cluster. The fix and details are in Canonical's security advisory. If you run an LXD or MicroCloud cluster whose HTTPS API is reachable by untrusted hosts, patch today.

What the bug does

The official Ubuntu CVE record describes it as "improper certificate validation in the HTTPS listener in Canonical LXD" that "allows an unauthenticated attacker to authenticate as any trusted client and gain full access to the cluster" via a crafted certificate chain.

In practice: the attacker attaches a trusted client's public certificate behind their own in the chain, and the server accepts the connection as that client. No private key is needed — only network reach to the HTTPS API and a copy of the trusted client's public certificate. If the impersonated account is privileged, Canonical says the attacker can reach root on the host. For MicroCloud, capturing a member's public certificate as it joins the cluster is enough to log in as that member.

Severity note

The CVE record carries a CVSS 10.0 base score. Canonical's own Ubuntu-package priority is listed as Medium — not a contradiction, but a scoping detail worth reading: the Ubuntu archive packages are marked not affected / not in release, so the exposed surface is the snap-distributed LXD and MicroCloud, plus Incus. Don't let the Medium package rating talk you out of patching a snap deployment.

Affected and fixed versions

The flaw affects LXD branches 4.0.14, 5.0.10, 5.21.8, and 6.9 and earlier. Fixed snap releases:

1. 6/stable → 6.10.1
2. 5.21/stable → 5.21.9
3. 5.0/stable → 5.0.11
4. 4.0/stable → 4.0.15
5. MicroCloud: 3/stable → 3.4.1, 2/stable → 2.1.5

Incus fixed the same flaw in 7.6.0 (GHSA-xg75-xf37-cph9); the Incus project reported it, and Canonical confirmed LXD was affected. Canonical notes the fixed LXD point releases were still promoting from candidate to stable, so verify the version you actually land on after a snap refresh.

Exploitation status

No reports of exploitation in the wild. A CISA assessment dated October 30 lists it as not known to be exploited, and it is not on the Known Exploited Vulnerabilities catalog. No public proof-of-concept has surfaced. That does not buy much time for an internet-reachable cluster API carrying a CVSS 10.0 auth bypass.

Action checklist

1. Refresh to the fixed release for your branch and confirm the installed version afterward — don't assume the channel served the patched build.
2. Restrict the HTTPS API to trusted networks. The attack needs network reach to the listener; firewalling it off is an immediate compensating control.
3. Rotate client certificates that may have been exposed, and prune trusted clients you no longer need from the trust store.
4. Audit cluster access logs for connections from unexpected source addresses during the exposure window.

Context

This is a certificate-chain validation bug — the same class that has bitten TLS stacks for years — landing in the control plane of a hypervisor and clustering layer, where "authenticate as any trusted client" means the whole fleet. It also lands in a codebase shared across LXD, MicroCloud, and Incus, so the fix and the exposure propagate across three projects at once. For infrastructure that terminates trust between cluster members, the practical takeaway is that a public certificate is not a secret, and anything that treats it as one is one crafted chain away from full access.