Canonical just patched a maximum-severity flaw in LXD and MicroCloud, because an attacker could log in as a trusted client without ever holding that client's private key, and if the impersonated account was privileged, that meant root access to the host machine.

The vulnerability is tracked as CVE-2026-112816, it carries a CVSS score of 10.0, and Canonical has released fixed versions of both products. Here is exactly what went wrong.

How the TLS Bypass Actually Worked

LXD and MicroCloud let remote clients access their APIs over mutual TLS, which is a setup where the client presents a certificate to prove who it is. A client is trusted when its certificate is in the server's trust store, the list of identities the server will accept.

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 at all, attach it to the chain behind their own, and the server would accept them as that client.

That is the entire attack. No private key required. Just a public certificate and network access to the HTTPS API.

Who Is Actually Affected

Exploiting 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.

The Incus Connection

Here is an interesting wrinkle. 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, which also patched 17 other security issues. So if you run Incus, you need to move to 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.

What to Do Right Now

Update LXD and MicroCloud to the fixed versions. On a snap install, run:

• sudo snap refresh lxd
• sudo snap refresh microcloud

There is one thing to watch out for. 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.

Is This Being Exploited?

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.

That is good news, but with a CVSS score of 10.0, you should treat this as urgent anyway.

FAQ

What is CVE-2026-112816?

It is a mutual TLS flaw in Canonical's LXD and MicroCloud. An attacker can impersonate a trusted client by attaching a public certificate to a fake certificate chain, without ever holding the private key.

Does this require a private key?

No. That is the scary part. The server only verified that the first certificate in the chain had a matching private key. The attacker used their own certificate for that and attached the trusted client's public certificate behind it.

Is my standalone LXD server affected?

Only if you enabled the network API with core.https_address. A default LXD install listens only on a local socket and does not expose the API to the network.

How do I fix it?

Run sudo snap refresh lxd and sudo snap refresh microcloud. Then verify the version actually updated, because Canonical warned that some releases were still rolling out from the candidate channel.

Has this been exploited in the wild?

No. As of October 30, CISA's assessment on the CVE record says the flaw is not known to have been exploited, and no working exploit has been published.

Source : The Hacker News