Follow us on Google News
A maximum-severity vulnerability in Canonical’s LXD and MicroCloud platforms could allow attackers to impersonate trusted clients without possessing their private keys, potentially giving them access to clusters, virtual machines and, in some cases, root-level control of host systems.
The flaw, tracked as CVE-2026-112816, carries a CVSS score of 10.0. Canonical has released fixed versions of both LXD and MicroCloud and urged users to update affected systems.
The vulnerability affects the way LXD and MicroCloud validate certificates used for mutual TLS authentication. An attacker would need network access to the HTTPS API and the public certificate of a client already trusted by the target server.
Flaw Affected Certificate Validation
LXD and MicroCloud allow remote clients to connect to their APIs using mutual TLS.
Under this model, the client presents a certificate to prove its identity, while the server checks whether that certificate belongs to a trusted client.
The vulnerability arose because the server compared every certificate supplied in the certificate chain against its trust store.
However, a TLS connection only proves that the connecting party possesses the private key associated with the first certificate in the chain, known as the leaf certificate.
The remaining certificates can be supplied by the client.
This meant an attacker could use their own certificate as the leaf certificate and attach the public certificate of a trusted client further down the chain.
Because the server checked every certificate against its list of trusted identities, it could incorrectly authenticate the attacker as the legitimate trusted client.
The trusted client’s private key was not required.
Attack Could Lead to Root Access
If the attack succeeded, the malicious user could act with the privileges of the impersonated client.
That could provide access to the LXD or MicroCloud cluster and the virtual machines managed through it.
Canonical said that if the compromised identity had sufficient privileges, an attacker could potentially obtain root access to the underlying host system.
The impact would therefore depend heavily on the permissions assigned to the trusted certificate being impersonated.
To exploit the vulnerability, an attacker would still need two important conditions: access to the target system’s HTTPS API and possession of the public certificate of an already trusted client.
Public certificates are not generally treated as secrets, making the second requirement less restrictive than obtaining a private key.
Standalone LXD Servers Have Limited Exposure by Default
Standalone LXD installations are not automatically exposed to this attack over the internet.
By default, LXD listens only on a local socket.
Administrators must explicitly enable network access to the API using the core.https_address configuration option before it becomes reachable over a network.
Systems where the API has been exposed to untrusted networks face greater risk.
MicroCloud environments may present a particular concern because multiple systems are joined together into a cluster.
Canonical said an attacker capable of capturing a cluster member’s public certificate while that system is joining MicroCloud could later use the certificate to impersonate that member.
This makes control over network access and certificate handling particularly important in clustered deployments.
Canonical Releases Fixed Versions
Canonical has released patched versions across multiple supported LXD channels.
Affected LXD releases include versions before 4.0.15, 5.0.11, 5.21.9 and 6.10.1.
The fixed LXD versions are 6.10.1 on the 6/stable channel, 5.21.9 on 5.21/stable, 5.0.11 on 5.0/stable and 4.0.15 on 4.0/stable.
For MicroCloud, the fixed releases are 3.4.1 on the 3/stable channel and 2.1.5 on 2/stable.
Canonical also warned that some fixed releases were still moving from candidate channels to stable at the time of its advisory.
Administrators were therefore advised to verify the version actually installed after performing an update rather than assuming the patched release had already been delivered.
Ubuntu archive packages of LXD were listed as either unaffected or not shipped, meaning the relevant updates apply primarily to snap-based installations.
Incus Project Reported Same Vulnerability
The issue was first reported by the Incus project, which began as a community fork of LXD.
Incus identified the same certificate validation weakness and released version 7.6.0 to address it.
Canonical later confirmed that LXD was affected by the same underlying problem.
Incus 7.6.0 fixed this vulnerability along with several other security issues.
The overlap illustrates how vulnerabilities affecting shared or historically related codebases can impact multiple infrastructure platforms even after projects have diverged.
No Known Exploitation Reported
There is currently no public indication that CVE-2026-112816 has been exploited in real-world attacks.
A CISA assessment dated October 30 listed the vulnerability as not known to have been exploited.
The flaw has also not been added to CISA’s Known Exploited Vulnerabilities catalogue, and no working public exploit has been reported.
However, the maximum CVSS score and the possibility of trusted-client impersonation make it a serious issue for exposed LXD and MicroCloud environments.
Canonical has not provided a temporary configuration-based workaround for affected LXD installations.
Because exploitation requires network access to the API, restricting access to trusted systems can reduce exposure until updates are installed.
Incus similarly advised users that there was no configuration fix and that limiting access to the network listener was the primary temporary mitigation.
Administrators using affected LXD or MicroCloud deployments should update to patched releases, verify the installed version and review whether their HTTPS APIs are exposed more widely than necessary.
The vulnerability highlights the importance of correctly validating certificate chains in mutual TLS environments. A flaw in trust evaluation can undermine strong authentication controls and allow attackers to assume the identity of legitimate infrastructure clients without ever obtaining their private keys.
About the author — Suvedita Nath is a science student with a growing interest in cybercrime and digital safety. She writes on online activity, cyber threats, and technology-driven risks. Her work focuses on clarity, accuracy, and public awareness.
