A high-severity vulnerability has been uncovered in Canonical’s LXD and MicroCloud platforms, enabling attackers to pose as trusted clients without needing their private key. The flaw, tagged as CVE-2026-112816 and given the maximum CVSS score of 10.0, exposes cluster APIs over HTTPS to impersonation attacks when certain conditions align.
Vulnerability Details and How It Works
LXD and MicroCloud typically secure client access via mutual TLS, where the client authenticates by presenting a certificate. The server maintains a trust store of trusted client certificates and checks incoming connections against these entries.
The bug arises because the server only verifies that the firstcertificate in the chain—the leaf—is legitimately linked to its private key, but does not validate certificates further up the chain. That lapse allows an attacker to take a public certificate from a trusted client (which is by itself non-secret), append it behind their own certificates, and successfully impersonate that trusted client in the eyes of the server.
Systems Impacted and Attack Vector
To exploit this flaw, an attacker needs two things: network access to the HTTPS API endpoint, and the public certificate of a client already trusted by the server. By default, standalone LXD servers do not expose their API over the network unless the administrator explicitly enables it (using the core.https_addresssetting). MicroCloud, which clusters multiple LXD hosts, offers a more sensitive exposure: when a new node joins the cluster, its public certificate can be captured—an attacker with that can later log in as that member.
The vulnerable versions include LXD 4.0.14, 5.0.10, 5.21.8 and 6.9, plus matching MicroCloud versions. Canonical has published fixed snap versions: 6.10.1 (for LXD 6/stable), 5.21.9, 5.0.11, 4.0.15, and for MicroCloud 3.4.1 and 2.1.5. A community-led project, Incus (a fork of LXD), has also patched this issue in its 7.6.0 release.
Status of Exploitation & Mitigation Guidance
Canonical reports no evidence so far that the flaw has been exploited in the wild. After an assessment by U.S. CISA on October 30, it was confirmed that the vulnerability is not listed among known exploited vulnerabilities, and no working exploit has been released.
The primary mitigation is updating affected systems to the fixed versions. On installations using snaps, the commands sudo snap refresh lxdand sudo snap refresh microcloudshould be used. Administrators are urged to confirm the version after refreshing, since fixed releases are rolling out gradually. No effective configuration workaround exists beyond limiting network access to the HTTPS API. Incus users should upgrade to version 7.6.0, which also addresses 17 other security issues.
Why this matters:Mutual TLS is a linchpin for securing many cloud and cluster-based architectures. A flaw that lets an attacker impersonate trusted clients—even without private keys—undermines fundamental assumptions about identity verification. For organizations relying on LXD or MicroCloud for virtualization or cluster management, this vulnerability represents a severe risk: compromised nodes, root access, lateral movement. Watch for whether downstream distribution packages (beyond snaps) are also affected, how rapidly fixes are adopted, and whether similar certificate-chain issues exist in comparable technologies. Keeping certificates and trust chains robust, and valuing private keys isn’t enough if your verification logic is flawed.
