Canonical patches critical LXD, MicroCloud flaw that lets attackers impersonate trusted clients

A maximum-severity vulnerability in Canonical's LXD and MicroCloud allows attackers to impersonate trusted clients without holding a private key. Update to the fixed snap releases and restrict network access to the HTTPS API.

A critical vulnerability in Canonical's LXD container manager and MicroCloud cluster platform lets an attacker log in as a trusted client without holding that client's private key. The flaw, tracked as CVE-2026-112816 , carries a CVSS score of 10.0. Canonical has released fixed versions of both products.

The bug lives in the mutual TLS authentication that protects the HTTPS API. LXD and MicroCloud ask clients to present a certificate, then check that certificate against a server-side trust store. The code compared every certificate in the client's chain against the store. A TLS handshake proves ownership of the leaf certificate's private key, not the rest of the chain. The rest of the chain is whatever the client chooses to attach.

An attacker can take a trusted client's public certificate, attach it behind their own leaf in the chain, and present the bundle. The code finds the trusted public certificate in the chain and grants access to the attacker as that client. Once inside, the attacker gains the client's access to the cluster and its virtual machines. If the impersonated account holds privileges, Canonical said the attacker could gain root access to the host machine.

The attack requires two conditions: network reachability to the HTTPS API, and possession of a trusted client's public certificate. A standalone LXD server does not expose the API over the network by default; it listens on a local socket unless an administrator enables remote access with the core.https_address setting.

MicroCloud carries a specific exposure. Canonical said an attacker who captures a cluster member's public certificate as that member joins the cluster can then impersonate it. The CVE record lists affected LXD versions as 4.0.14, 5.0.10, 5.21.8 and 6.9, each prior to the fixed release.

Canonical lists these fixed snap versions:

The Incus project, a community fork of LXD, reported the flaw. Canonical confirmed it affects LXD as well. Incus fixed the same issue in version 7.6.0 , along with 17 other security problems. The CVE record lists Ubuntu's archive packages for LXD as not affected or not shipped; users should rely on the snap releases.

No public evidence shows attackers have exploited this flaw. A U.S. CISA assessment dated October 30 lists it as not known to have been exploited. It does not appear on CISA's Known Exploited Vulnerabilities catalog, and no one has published a working exploit.

Update LXD and MicroCloud to the fixed snap versions. Run sudo snap refresh lxd and sudo snap refresh microcloud . Canonical noted that the fixed LXD point releases were still rolling out from the candidate channel to stable at the time of the advisory, so verify the installed version after the refresh rather than assume the fix arrived.

Canonical offers no temporary workaround for LXD. Because the attack depends on reaching the HTTPS API, restricting network access to that listener lowers risk until you patch. The Incus project said there is no configuration fix; the only mitigation is to limit network access to the listener. Incus users should upgrade to 7.6.0.

Don't leave that gap open. Verify your snap versions now.

Source : thehackernews.com