Canonical has published fixed builds of LXD and MicroCloud after finding that the container managers would accept a client they had never actually authenticated. The flaw is tracked as CVE-2026-112816 and carries a CVSS score of 10.0.
Both products expose their APIs over mutual TLS, where a client presents a certificate to prove its identity. The server checked every certificate in the submitted chain against its trust store.
The chain that was not verified
That check was wrong in a specific way. A TLS handshake only proves the sender holds the private key for the first certificate, the leaf. The rest of the chain is whatever the client chooses to attach.
An attacker could therefore take a trusted client’s public certificate, which is not secret, hang it behind their own, and be treated as that client. Privileged accounts meant root access to the host.
What you need to reach it
Two things are required: network access to the HTTPS API and the public certificate of an already-trusted client. A standalone LXD server does not expose the API unless an administrator enables it with core.https_address.
MicroCloud is the softer target. Anyone who captures a member’s certificate as it joins the cluster can later log in as that member.
Fixed versions
Snap users should move to LXD 6.10.1, 5.21.9, 5.0.11 or 4.0.15, and MicroCloud 3.4.1 or 2.1.5. Canonical’s fixed point releases were still rolling from candidate to stable when the advisory shipped, so verify the version after refreshing.
The Incus project reported the bug first, and patched it in 7.6.0. CISA recorded on October 30 that no exploitation is known, and nothing has been added to the KEV catalog.
