CVSS 10.0 Flaw in LXD and MicroCloud Lets Attackers Impersonate Trusted Clients

Canonical has released fixed versions of LXD and MicroCloud for a critical flaw that 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 and requires network access to the HTTPS API plus the trusted client's public certificate. If the impersonated account is privileged, the attacker could gain root access to the host machine, Canonical said.

How the flaw works

LXD and MicroCloud let remote clients access their APIs over mutual TLS, where the client presents a certificate to prove its identity. A client is trusted when its certificate is in the server's trust store. The flaw was in how the server checked that certificate: it compared every certificate the client sent against the trust store, but a TLS connection only proves the client owns the private key for the first certificate in the chain, the leaf. The rest of the chain is whatever the client chose to attach, so an attacker could take a trusted client's public certificate, which is not secret, attach it behind their own, and be accepted as that client.

Who is affected

Using the flaw takes two things: network access to the HTTPS API, and the public certificate of a client the server already trusts. A standalone LXD server does not expose that API by default; it listens only on a local socket unless an administrator turns on the network API with the core.https_address setting. MicroCloud, which ties several machines running LXD into one cluster, has a specific weak point: Canonical said an attacker who can capture a member's public certificate as it joins the cluster can then log in as that member. The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before the fixed release that follows.

Fixed versions

Canonical lists these fixed snap versions: 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, and MicroCloud 2/stable 2.1.5. The bug did not start at Canonical: the Incus project, which began as a community fork of LXD, reported it, and Canonical confirmed it affected LXD as well. Incus fixed the same flaw in version 7.6.0. Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the fixed releases are the snaps. There is no public sign the flaw has been used in an attack. The CVE record carries a U.S. CISA assessment, dated October 30, that the flaw is not known to have been exploited; it is not on CISA's Known Exploited Vulnerabilities list, and no working exploit has been published.

What to do

Update LXD and MicroCloud to the fixed versions. On a snap install, run sudo snap refresh lxd and sudo snap refresh microcloud. Canonical said the fixed LXD point releases were still rolling out from the candidate channel to stable at the time of its advisory, so check the version you actually have after the refresh rather than assume the fix arrived. Canonical's advisory gives no temporary workaround for LXD. Because the attack requires network access to the API, limiting who can reach it reduces risk until you update. The Incus project, reporting the same flaw, said there is no configuration fix and that the only step is to restrict network access to the listener. Incus users should move to 7.6.0, which fixed this flaw along with 17 other security issues.

Sources: The Hacker News