Cybersecurity experts have uncovered a critical security vulnerability affecting Canonical’s LXD and MicroCloud platforms, potentially allowing attackers to impersonate trusted clients and gain unauthorised access to cloud infrastructure without possessing the victims’ private encryption keys.
The vulnerability, tracked as CVE-2026-112816, carries the maximum possible Common Vulnerability Scoring System (CVSS) rating of 10.0, making it a critical security threat to organisations using the affected software.
According to Canonical, successful exploitation could allow an attacker to access a compromised cluster and interact with its virtual machines while impersonating an already trusted client.
The company warned that when the impersonated client has administrative privileges, the attacker could potentially obtain root-level access to the underlying host machine.
Canonical has released security updates for both LXD and MicroCloud to address the vulnerability and urged administrators to upgrade their installations.
How the Security Vulnerability Works
LXD and MicroCloud use mutual Transport Layer Security (mTLS) to authenticate remote clients connecting to their application programming interfaces (APIs).
Under this security arrangement, a client presents a digital certificate to demonstrate its identity, while the server checks whether the certificate belongs to an authorised user or system recorded in its trusted certificate store.
However, security researchers discovered a weakness in the way the affected platforms validate certificate chains.
The vulnerability allows an attacker to manipulate the certificate verification process by attaching the publicly available certificate of an already trusted client to a certificate chain associated with their own connection.
Although the attacker does not possess the trusted client’s private key, the affected software incorrectly accepts the connection because it checks certificates presented within the chain without properly establishing that the connecting party controls the private key corresponding to the trusted certificate.
This authentication weakness effectively allows an attacker to assume the identity of a legitimate client.
Once the impersonation succeeds, the attacker could gain access to resources and systems available to the compromised client’s account.
Systems and Organisations at Risk
Exploitation of CVE-2026-112816 requires two major conditions.
First, the attacker must have network access to the HTTPS API exposed by the affected LXD or MicroCloud installation.
Second, the attacker must obtain the public certificate belonging to a client already trusted by the server.
Canonical explained that standalone LXD installations do not expose their HTTPS API over the network by default. Administrators must explicitly enable the network interface by configuring the core.https_address setting.
However, MicroCloud deployments present an additional security concern because the platform connects multiple LXD machines to operate as a unified cluster.
According to Canonical, an attacker who manages to capture the public certificate of a cluster member while it is joining the environment could subsequently exploit the vulnerability to authenticate as that member.
The affected LXD versions include 4.0.14, 5.0.10, 5.21.8 and 6.9, alongside earlier releases before their respective security fixes.
Canonical has published the following patched versions:
| 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 |
The vulnerability was initially reported through the Incus project, a community-developed fork of LXD. Canonical subsequently confirmed that its LXD platform was also affected.
The Incus project addressed the same security weakness in version 7.6.0.
Canonical also clarified that the affected Ubuntu archive packages of LXD were either not vulnerable or were not distributed through the relevant archive channels. The security fixes are available through the Snap releases.
No Confirmed Evidence of Active Exploitation
Despite the severity of the vulnerability, there was no publicly available evidence indicating that attackers had successfully exploited it at the time of the security advisory.
The US Cybersecurity and Infrastructure Security Agency (CISA) assessment dated October 30, 2026, indicated that the vulnerability was not known to have been exploited in cyberattacks.
It has also not been included in CISA’s Known Exploited Vulnerabilities (KEV) catalogue, and no publicly available working exploit had been reported.
Nevertheless, security specialists warn that the maximum CVSS rating highlights the potential consequences of successful exploitation, particularly for organisations operating large virtualisation environments and cloud infrastructure.
How Organisations Can Protect Their Systems
Canonical has advised administrators to install the updated versions of LXD and MicroCloud to prevent potential exploitation.
For systems installed through Snap, administrators can execute the following commands to refresh the software:
sudo snap refresh lxd
sudo snap refresh microcloudHowever, administrators should verify the installed versions after updating because Canonical disclosed that some fixed LXD releases were still moving from the candidate channel to the stable channel when its advisory was published.
The company did not provide a temporary configuration-based workaround for the LXD vulnerability.
Since exploitation requires network access to the affected HTTPS API, organisations are advised to restrict access to the API listener and ensure that only authorised systems can communicate with it until security updates have been successfully installed.
The Incus project similarly recommended restricting network access to its API interface, noting that there was no configuration change capable of completely resolving the underlying vulnerability.
Organisations running Incus are advised to upgrade to version 7.6.0, which addresses the authentication flaw alongside 17 other security issues.
The discovery underscores the growing cybersecurity risks associated with cloud infrastructure and virtualisation platforms, where weaknesses in authentication mechanisms can potentially expose entire clusters and their underlying host systems to unauthorised access.