A critical certificate-validation flaw in Canonical’s LXD and MicroCloud can let an attacker impersonate a trusted client without possessing its private key, potentially gaining access to a cluster and its virtual machines. Tracked as CVE-2026-112816, the vulnerability carries a CVSS 4.0 score of 10.0.
Canonical published its security advisory on October 28. It says the remote API compared every certificate in a client’s presented chain with its trust store. But mutual TLS proves possession of the private key only for the leaf certificate. An attacker who can reach the HTTPS API and obtain a trusted client’s public certificate could attach it to another chain and be accepted as that client. The Hacker News reported on the flaw on November 1.
The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected. Canonical’s fixed snap releases are LXD 4.0.15, 5.0.11, 5.21.9 and 6.10.1, along with MicroCloud 2.1.5 and 3.4.1. The Incus project published a separate advisory for the same class of certificate-chain flaw and fixed it in Incus 7.6.0.
Exposure depends on configuration. A standalone LXD installation uses a local Unix socket by default and does not expose its HTTPS API until an administrator sets core.https_address, according to the LXD documentation. MicroCloud clusters have an additional risk because a joining member’s public certificate can be intercepted and then used to impersonate that member.
If this article helped you, please consider supporting our work. Every small contribution keeps Abijita.com independent and running.
