LXD and MicroCloud flaw let attackers pose as any trusted client using only its public certificate

Canonical disclosed CVE-2026-112816 on October 28, a maximum-severity flaw in the HTTPS API of its LXD container and virtual machine manager and of MicroCloud, which clusters LXD machines. Clients authenticate to that API with mutual TLS, and a client is trusted when its certificate is in the server's trust store. The server compared every certificate the client sent against that store, but a TLS handshake only proves the client holds the private key for the first, leaf certificate. An attacker could attach a trusted client's public certificate behind their own and be accepted as that client, with access to the cluster and its virtual machines, and root on the host if the impersonated client is privileged. Fixed releases are LXD 4.0.15, 5.0.11, 5.21.9 and 6.10.1. The Incus project, an LXD fork, reported the bug and fixed it in Incus 7.6.0.

Why it matters

This is a chain validation bug, not a cryptography break: the server accepted an identity the client never proved it held. Public certificates are not secrets, and Canonical says an attacker who captures a MicroCloud member's certificate as it joins the cluster can log in as that member, so the real bar is network reach to the API. A standalone LXD server only exposes the API if an administrator sets core.https_address. CISA's assessment in the CVE record says it is not known to be exploited.

Run snap refresh lxd and snap refresh microcloud, then check the installed version, since Canonical said point releases were still moving to stable. Until then, restrict who can reach the listener; neither Canonical nor Incus offers a configuration workaround. Anyone writing mTLS authorization should bind it to the leaf certificate whose key was proven. Our certificate lifecycle guide covers client certificates, and the X.509 entry explains what a certificate chain does and does not prove.

Source: Canonical security advisory