Canonical has released patches for CVE-2026-112816, a critical vulnerability in LXD and MicroCloud that allows an attacker to authenticate as any trusted TLS client and gain full access to the cluster and managed virtual machines. To exploit it, the attacker only needs network access to the HTTPS API and the public certificate of a trusted client — the private key is not required. If the compromised account has elevated privileges, the attacker can obtain root access to the host machine. LXD and MicroCloud administrators must immediately update snap packages to the fixed versions.
Vulnerability mechanism
LXD and MicroCloud use mutual TLS for authenticating remote clients: the client presents a certificate, and the server checks whether it is present in the trust store. The issue lay in how exactly the server performed this check.
According to the Canonical security advisory, the authentication logic compared all certificates sent by the client in the chain against entries in the trust store. However, the TLS handshake only proves possession of the private key for the first certificate in the chain — the leaf certificate. The rest of the certificates in the chain are fully controlled by the client.
This means an attacker could construct a certificate chain by placing their own leaf certificate first and the public certificate of a trusted client as an intermediate. The server would find the trusted certificate in the chain and accept the connection on behalf of that client, even though the attacker did not possess its private key.
Affected versions and patches
According to the Ubuntu CVE page, the following LXD versions are affected:
- LXD 4.0.14 (fixed in 4.0.15)
- LXD 5.0.10 (fixed in 5.0.11)
- LXD 5.21.8 (fixed in 5.21.9)
- LXD 6.9 (fixed in 6.10.1)
For MicroCloud, Canonical has released fixed versions 2.1.5 and 3.4.1. All patches are dated 29 October 2026 and are distributed through snap channels.
The vulnerability was not discovered by Canonical itself. The Incus project — a community-maintained fork of LXD — was the first to report the issue, after which Canonical confirmed that the same flaw affects LXD. Incus fixed the vulnerability in version 7.6.0 — this is a separate product, and its version does not replace LXD or MicroCloud updates.
Clarification on severity rating
Some publications attribute a CVSS score of 10.0 to this vulnerability. However, Canonical’s advisory for LXD and MicroCloud labels the issue as critical without specifying a numeric score. The 10.0 rating explicitly appears in the Incus security advisory for the same certificate-chain vulnerability. Since this is the same class of flaw, the rating is substantively applicable, but formally it was assigned by the Incus project, not by Canonical.
Differences in attack vectors: LXD vs. MicroCloud
Practical exploitation paths differ between the products. For a standalone LXD server, the attack requires network reachability of the HTTPS API, which is not open by default — it listens only on the local socket unless the administrator has enabled the core.https_address setting.
MicroCloud, which combines multiple LXD machines into a single cluster, introduces an additional vector: according to Canonical, an attacker who can intercept a node’s public TLS certificate at the moment it joins the cluster can later authenticate as that node. This makes the process of adding new members to the cluster a particularly sensitive point.
When prioritizing remediation, focus first on installations with exposed API listeners and environments where cluster expansion operations are being carried out.
Exploitation status
Based on available information, there are no signs of active exploitation of this vulnerability. CVE-2026-112816 is not listed in the CISA Known Exploited Vulnerabilities catalog, and no public exploits have been released. However, the absence from the KEV catalog is not, by itself, proof that exploitation has not occurred.
Recommendations
To remediate the vulnerability:
- Update snap packages with
sudo snap refresh lxdandsudo snap refresh microcloud - After updating, verify the actual version — at the time of Canonical’s advisory, LXD fixes were in the process of gradually moving from the
candidatechannel tostable - Incus users must update to version 7.6.0
No configuration-based workaround exists — this is explicitly stated by both Canonical and the Incus project. Until the update is installed, the only risk mitigation measure is to restrict network access to the HTTPS listener to trusted hosts.
We have previously covered critical vulnerabilities in the Ubuntu ecosystem — for example, the pedit COW privilege escalation vulnerability in the Linux kernel. CVE-2026-112816 is different in that the attack targets not the kernel, but the container and virtual machine orchestration layer, which, if successfully exploited, provides access to the entire cluster at once.
Given the lack of workarounds and the potential scope of compromise — from access to virtual machines up to root access on the host — updating LXD and MicroCloud snap packages to the fixed versions is the only complete protection measure, and it should be carried out without delay, especially on installations with an exposed network API.
