Cybersecurity Hacking and Exploits

Critical CVE-2026-112816: LXD and MicroCloud Permit Trusted Client Impersonation (CVSS 10.0)

LXD and MicroCloud security illustration

A newly disclosed critical vulnerability affecting Canonical’s LXD and MicroCloud allows an attacker to authenticate as a trusted client without possessing that client’s private key. Because the flaw undermines the server’s certificate checks during mutual TLS authentication, an attacker with network access to the HTTPS API and a trusted client’s public certificate can present a crafted certificate chain and be accepted as the trusted identity. Canonical has released patched snap builds; administrators should treat this as urgent because a privileged impersonation could lead to root-level access on host machines.

How the Flaw Works

LXD and MicroCloud rely on mutual TLS (mTLS) for API authentication: clients present certificates and the server consults a trust store to decide which client identities to accept. The vulnerability stems from how the server verifies the presented chain against that trust store. The server compared all certificates the client sent to entries in the trust store, but a TLS connection cryptographically proves possession of the private key only for the leaf certificate — the first certificate in the chain. The rest of the chain is supplied by the client and is not validated for private-key ownership.

An attacker can take a publicly available client certificate that the server already trusts, append it to a chain behind their own leaf certificate, and the server will treat the session as if it belonged to the trusted client. With that identity, the attacker gains the same API privileges as the impersonated client; if that client has elevated rights within a cluster or on a host, the attacker may be able to obtain root access to the underlying machine.

Who Is Affected

Exploitation requires two things: network access to the LXD/MicroCloud HTTPS API and the public certificate of a client already trusted by that server. A standalone LXD installation does not expose the network API by default — it listens on a local socket unless an administrator enables the network listener (core.https_address). Systems that have explicitly opened the API to the network are at greater risk.

MicroCloud clusters are particularly sensitive during node join operations: an attacker able to capture a member’s public certificate as it joins the cluster could later use that certificate to log in as the member. Canonical lists several affected versions and the corresponding fixed snap releases:

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

Origin, Discovery, and Current Threat Assessment

The issue was reported by the Incus project — a community fork that originated from LXD — which fixed the bug in Incus 7.6.0. Canonical validated the problem and released patched snap versions for LXD and MicroCloud. Ubuntu archive packages of LXD are listed as not affected or not shipped; the fixes are distributed via snaps.

At the time of the advisory, there was no public evidence the flaw had been exploited in the wild. The CVE entry carries a U.S. CISA assessment (dated October 30) stating the vulnerability is not known to have been exploited and it is not listed on CISA’s Known Exploited Vulnerabilities catalog. No working exploit has been published publicly.

Mitigation and Recommended Actions

The definitive fix is to update to the patched releases. On snap-managed systems, run:

code
sudo snap refresh lxd
sudo snap refresh microcloud

After refreshing snaps, verify the installed versions because Canonical warned that the patched point releases were still progressing from candidate to stable channels at the time of the advisory.

There is no configuration-only workaround for LXD beyond reducing exposure: since exploitation requires network access to the API, administrators should restrict which hosts can reach the listener (for example, avoid enabling core.https_address on publicly reachable interfaces or apply strict network ACLs). Incus similarly reported no configuration fix and recommended limiting network reachability. Incus users should upgrade to Incus 7.6.0, which also addresses this flaw along with other security fixes.

Leave a Reply

Your email address will not be published. Required fields are marked *

🧰

Free Tools: IP, DNS, SSL

40+ free network and other tools in one place. No signup. Click explore or visit https://technochat.in/tools

Explore