LXD, MicroCloud flaw lets clients be impersonated

A trusted client's identity in LXD and MicroCloud rests on a certificate sitting in the server's trust store. According to Canonical, an attacker who could reach the HTTPS API over the network and obtain that client's public certificate could log in as that client — no private key required. The bug is tracked as CVE-2026-112816 and carries a maximum CVSS score of 10.0.

Canonical has released fixed versions of both products. The flaw did not originate at Canonical: the Incus project, which began as a community fork of LXD, reported it, and Canonical confirmed that LXD was affected as well.

Trust built on mutual TLS

LXD and MicroCloud expose their APIs to remote clients over mutual TLS. In that arrangement, the client presents a certificate to prove who it is, and a client counts as trusted when its certificate appears in the server's trust store — the list of identities the server will accept.

The problem lay in how the server validated that certificate. It compared every certificate the client sent against the trust store, but a TLS connection only proves the client holds the private key for the first certificate in the chain, the leaf. Everything after the leaf is whatever the client chose to attach.

That mismatch gave an attacker a path in. The public certificate of a trusted client is not secret. Attaching it to the chain behind the attacker's own certificate meant the server would accept the connection as coming from that trusted client.

What an impersonator could reach

Once accepted, the attacker would act as the impersonated client, with access to the cluster and its virtual machines. If the account being impersonated is privileged, the consequences escalate: Canonical said the attacker could gain "root access to the host machine."

The Incus project's advisory takes the same line on the underlying mechanism, noting there is no configuration fix for the flaw and that the only step available is to restrict network access to the listener.

The bar to exploitation

Two things are needed to use the flaw. The first is network access to the HTTPS API. The second is 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, which means default standalone deployments are not reachable this way.

MicroCloud carries a more specific weak point. The product ties several machines running LXD into a single cluster, and Canonical said an attacker who can capture a member's public certificate as it joins the cluster can then log in as that member.

Versions that need replacing

The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each prior to the fixed release that follows it. Canonical lists the fixed snap versions by channel:

• LXD on the 6/stable channel: fixed in 6.10.1
• LXD on the 5.21/stable channel: fixed in 5.21.9
• LXD on the 5.0/stable channel: fixed in 5.0.11
• LXD on the 4.0/stable channel: fixed in 4.0.15
• MicroCloud on the 3/stable channel: fixed in 3.4.1
• MicroCloud on the 2/stable channel: fixed in 2.1.5

Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the snaps are where the fixes apply.

Incus fixed it first

Incus shipped the fix for the same flaw in version 7.6.0, which addressed this issue alongside 17 other security problems. The project published a security advisory describing the issue it had reported.

Canonical's own advisory documents the affected and fixed releases for LXD and MicroCloud, and the CVE record carries the scoring and exploitation status for the flaw.

No sign of attacks yet

There is no public indication that 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.

That status could change, but as of the advisory record it reflects the absence of observed exploitation rather than a judgment that exploitation is impractical.

Updating and interim limits

The primary step is to update LXD and MicroCloud to the fixed versions. On a snap installation, that means running 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. Administrators should therefore check the version actually installed after the refresh rather than assume the fix has 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 an update is applied. Incus users should move to 7.6.0, which fixed this flaw along with the 17 other security issues included in that release.

Why this matters for operators

The flaw sits in the layer that is supposed to establish identity, and it turns a piece of information that was never meant to be secret — a public certificate — into a usable credential when combined with network reach. For teams running MicroCloud clusters, the exposure window around a member joining is the part that may deserve the closest attention, since that is when Canonical says a public certificate can be captured and later reused.

Because no working exploit has been published, the immediate risk appears to hinge on whether an API listener is reachable and whether any trusted client's certificate is obtainable. Restricting reachability to the API while the update rolls out is the step both projects point to. Operators who exposed the HTTPS API through core.https_address without restricting its reach should treat the update as the priority and verify the installed version afterward.