Canonical has disclosed and patched CVE-2026-112816, a maximum-severity authentication bypass in the HTTPS API listener of LXD, the system container and VM manager that also underpins MicroCloud. A crafted certificate chain lets a remote attacker authenticate as any trusted client, which can mean full control of a cluster and its managed instances. The CVE was published October 30, 2026. At the time of writing, no in-the-wild exploitation has been reported.
What happened
The bug is classified as CWE-295 (improper certificate validation). LXD authenticates API clients with mutual TLS: a client presents a certificate, and LXD checks it against its trust store. According to Canonical’s advisory, the API compared all peer certificates presented in the TLS chain against trust-store entries, but only the leaf certificate proves possession of the private key. An attacker who places a trusted certificate somewhere in the chain, while holding the key for a different leaf, is therefore treated as the identity behind the trusted certificate.
The CVE record describes this as exploitable by an unauthenticated attacker. The vendor advisory is more specific: the attacker needs a trusted public client certificate, which is not secret material, such as one seen on the wire or in a MicroCloud join. Treat the practical bar as low either way. The vendor reporter is Stéphane Graber, and CISA’s SSVC enrichment rates exploitation “none,” automatable “yes,” technical impact “total.”
Affected and fixed versions
| Branch | Affected | Fixed |
|---|---|---|
| LXD 6.x | 6.9.0 to before 6.10.1 | 6.10.1 |
| LXD 5.21 LTS | 5.21.8 to before 5.21.9 | 5.21.9 |
| LXD 5.0 LTS | 5.0.10 to before 5.0.11 | 5.0.11 |
| LXD 4.0 LTS | 4.0.14 to before 4.0.15 | 4.0.15 |
| MicroCloud 2.x | affected | 2.1.5 |
| MicroCloud 3.x | affected | 3.4.1 |
CVSS 4.0 vector: AV:N/AC:L/AT:N/PR:N/UI:N with high confidentiality, integrity and availability impact on both the vulnerable and subsequent systems, scoring 10.0.
Impact
Exposure depends on whether the HTTPS listener is enabled and reachable. A default LXD install that only serves the local Unix socket is not remotely exposed. Hosts that set core.https_address, and all clustered deployments (cluster members talk to each other over this listener), are in scope. MicroCloud is the highest-risk case: the advisory notes that an attacker who can intercept the public TLS certificate of a joining cluster member can later authenticate as that member.
Impersonating a trusted client inherits that client’s permissions. LXD admin identities can create privileged containers, mount host paths, and run commands on the host, so impersonating an administrator is effectively root on the hypervisor. In multi-tenant setups it also means access to every tenant’s instances, images, secrets in instance configs, and attached storage. For teams that use LXD as a lightweight VM and container platform on bare metal, this is a hypervisor-level compromise path.
Mitigation
Canonical lists no workaround. Upgrade:
| |
The advisory says the LXD point releases were in progressive rollout from candidate to stable, so snap refresh may not show the fixed build immediately. Check the installed version with lxd --version and pull from the relevant channel (6/stable, 5.21/stable, 5.0/stable, 4.0/stable) once available.
Until patched or confirmed fixed:
- Run
lxc config get core.https_addresson each host. If it is set, restrict reachability with host firewall rules or a management VLAN so only cluster peers and admin jump hosts can reach the port (default 8443). - Do not expose the LXD API to the internet or to untrusted tenant networks.
- Review the trust store (
lxc config trust list) and remove stale or unknown certificates. Trusted public certs are the raw material for the impersonation. - Audit API logs for connections whose presented chain contains more than one certificate, or administrative actions from unexpected source addresses.
- For MicroCloud, avoid joining new members over untrusted networks until upgraded.