**Canonical**, the company behind **Ubuntu**, has disclosed a critical security vulnerability, **CVE-2026-112816**, affecting its **LXD** container hypervisor and **MicroCloud** clustering solution. This flaw allows an attacker to authenticate as a trusted client without possessing the client's private key, potentially leading to full compromise of the host system. ### The Vulnerability Explained The vulnerability, which boasts a maximum CVSS score of 10.0, lies in the mutual TLS (mTLS) authentication process used by **LXD** and **MicroCloud** for remote API access. In mTLS, clients present a certificate to prove their identity, and the server verifies this against its trust store. However, the flaw meant that the server would compare *every* certificate in the client-provided chain against its trust store, rather than just the leaf certificate (the first in the chain) which proves the client's ownership of the private key. An attacker could exploit this by appending a trusted client's public certificate (which is not secret) to their own certificate chain, tricking the server into believing they are the legitimate, trusted client. Once authenticated as a trusted client, the attacker gains access to the cluster and its virtual machines. If the impersonated account has elevated privileges, this could result in root access to the underlying host machine. ### Who is Affected? Exploiting **CVE-2026-112816** requires two key conditions: 1. Network access to the HTTPS API of **LXD** or **MicroCloud**. 2. The public certificate of a client already trusted by the server. For a standalone **LXD** server, the network API is not exposed by default, only listening on a local socket unless explicitly enabled via the `core.https_address` setting. **MicroCloud** clusters, however, present a specific weak point: an attacker capable of intercepting a member's public certificate during its cluster join process could then use this to log in as that member. Affected **LXD** versions include 4.0.14, 5.0.10, 5.21.8, and 6.9, all prior to their respective fixed releases. **Canonical** has released snap versions with the fixes: | Product | Snap Channel | Fixed Version | | :--------- | :----------- | :------------ | | **LXD** | 6/stable | 6.10.1 | | **LXD** | 5.21/stable | 5.21.9 | | **LXD** | 5.0/stable | 5.0.11 | | **LXD** | 4.0/stable | 4.0.15 | | **MicroCloud** | 3/stable | 3.4.1 | | **MicroCloud** | 2/stable | 2.1.5 | It's worth noting that the bug was initially reported by the **Incus** project, a community fork of **LXD**, which subsequently fixed the same flaw in version 7.6.0. **Ubuntu**'s archive packages of **LXD** are listed as unaffected or not shipped, meaning the primary fix vector is through snap updates. As of the **U.S. CISA** assessment on October 30, there is no public indication that this flaw has been exploited in the wild, and it is not on CISA's Known Exploited Vulnerabilities list. ### Immediate Action Required All users of **LXD** and **MicroCloud** are strongly advised to update to the fixed versions without delay. For snap installations, execute the following commands: `sudo snap refresh lxd` `sudo snap refresh microcloud` **Canonical** noted that the fixed **LXD** point releases were still rolling out to the stable channel at the time of their advisory, so it is crucial to verify the installed version post-refresh. While **Canonical** has not provided a temporary workaround, limiting network access to the HTTPS API can mitigate risk until the update is applied. The **Incus** project similarly stressed that network restriction is the only alternative to patching. **Incus** users should upgrade to version 7.6.0, which addresses this and 17 other security issues.