Critical LXD and MicroCloud Flaw Lets Attackers Pose as Trusted Clients Without a Private Key

Why this matters: a flaw rated as severe as security scores get — and the fix is a version check, not a settings change

November 2, 2026 — A critical flaw in Canonical's LXD and MicroCloud let an attacker log in as a trusted client without holding that client's private key, according to reporting published on November 1, 2026. The flaw, tracked as CVE-2026-112816, carries the maximum CVSS score of 10.0, and Canonical has released fixed versions of both products.

Image: A symbolic illustration of glowing server racks and floating digital certificate badges, with one badge highlighted as mismatched. Credit: Red Eye Eagle News / AI illustration.

Editor's Highlight: The weakness is not a stolen password or a leaked secret key. It is a check that trusted the wrong part of a certificate chain — and that distinction is why public certificates, which are not secret, suddenly became enough to impersonate a trusted client.

Table of Contents

• What Happened
• How the Certificate Check Failed
• Who Is Affected — and Who Is Not
• The Fixed Versions
• What to Do Right Now
• Why a 10.0 Score Matters
• Bottom Line
• FAQ
• Sources

Key Facts

Detail	Information
Vulnerability	CVE-2026-112816, authentication bypass in LXD and MicroCloud
Severity	CVSS 10.0, the maximum score
Vendor	Canonical, maker of Ubuntu, LXD and MicroCloud
Reported by	The Incus project, a community fork of LXD
Attack requirement	Network access to the HTTPS API plus a trusted client's public certificate
Worst-case impact	Root access to the host machine, if the impersonated client is privileged
Exploitation status	Not known to have been exploited, per a CISA assessment dated October 30
Fix	Updated snap versions for LXD and MicroCloud; Incus 7.6.0

Background video: Canonical's introduction to LXD, the Linux container daemon at the centre of this story. It is context on what LXD is, not coverage of the flaw itself.

What Happened

LXD is Canonical's tool for running Linux containers and virtual machines. MicroCloud ties several machines running LXD together into a single cluster, so administrators can manage them as one system.

Remote clients talk to the LXD API over HTTPS, using certificates to prove who they are. This is called mutual TLS: the client presents a certificate, and the server checks it against a trust store — the list of identities the server has agreed to accept.

The flaw broke that check. An attacker who could reach the HTTPS API and who held a trusted client's public certificate could be accepted as that client, without ever holding the client's private key.

Once accepted, the attacker would act as that client, with access to the cluster and its virtual machines. If the impersonated account is privileged, Canonical said the attacker could gain root access to the host machine — the highest level of control over the underlying server.

Newsroom Focus: Root access matters because it is not limited to one container or one virtual machine. It can mean control of everything running on that host, which is why administrators are being urged to update rather than wait for a quieter moment.

How the Certificate Check Failed

The problem, in plain terms, is about which certificate a connection actually proves you own.

A TLS connection proves the client holds the private key for the first certificate in the chain — the leaf certificate. Any further certificates attached behind it are simply what the client chose to send along.

According to The Hacker News, the flawed server code compared every certificate the client sent against the trust store, instead of checking only the certificate whose private key had actually been proven.

That opened a simple path. An attacker could take a trusted client's public certificate — which, by design, is not secret — attach it to the chain behind their own certificate, and be accepted as that trusted client.

Think of it as a name badge that anyone can photocopy. The system was supposed to check the badge against the person wearing it. Instead, it checked whether the badge itself looked familiar, without confirming the wearer owned it.

Analysis Note: This is a useful reminder that "public" and "safe to share" are not the same as "safe to trust on sight." A public certificate is meant to be shared so others can verify signatures. It was never meant to serve, on its own, as proof of identity — and this flaw briefly let it do exactly that.

Who Is Affected — and Who Is Not

Exploiting the flaw takes two things, and both matter for judging your own risk.

• Network access to the LXD HTTPS API. Without a route to that API, the attack cannot start.
• The public certificate of a client the server already trusts. The attacker does not need the private key, but does need to know which public certificate to present.

A standalone LXD server does not expose that API by default. It listens only on a local socket unless an administrator deliberately turns on the network API with the core.https_address setting.

That detail narrows the exposure for many single-server setups. If the network API was never switched on, the remote path described in the reports is not open in the first place.

MicroCloud is the sharper concern. Because it links several machines into one cluster, its members need to talk to each other over the network. Canonical said an attacker who can capture a member's public certificate as it joins the cluster can then log in as that member.

SC Media's November 2 brief put the same point directly: standalone LXD servers are generally protected unless the network API was manually enabled, while MicroCloud clusters face higher risks because of their interconnected nature.

Ubuntu's own archive packages of LXD are listed as not affected or not shipped, according to The Hacker News, so the fixed releases to watch are the snaps.

The Fixed Versions

Canonical has released fixed snap versions for both products. The Hacker News lists the following fixed versions:

Product	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

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. If your version matches one of those, or sits below a fixed version on your channel, it needs attention.

The flaw 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.

Practical Takeaway: Do not assume a refresh worked. 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 refreshing, rather than assuming the fix arrived.

What to Do Right Now

For snap installations, the update commands reported by The Hacker News are:

• sudo snap refresh lxd
• sudo snap refresh microcloud

After refreshing, verify the installed version against the fixed-version table above. If the version has not moved to a fixed release, the rollout may not have reached your channel yet — check again rather than treating the refresh alone as proof.

Canonical's advisory gives no temporary workaround for LXD. That leaves network restriction as the main interim step: 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 short of patching is to restrict network access to the listener. Incus users should move to version 7.6.0.

For teams running clusters, the order of work is straightforward. First, restrict API access to trusted networks. Second, update every member, not just the first machine you check. Third, confirm each member's version after the update.

Why a 10.0 Score Matters

A CVSS score of 10.0 is the top of the scale, reserved for flaws that are both easy to exploit and devastating in effect. It does not mean every system is equally exposed — the network-access requirement still limits who can even attempt this attack.

It does mean the combination is unusually dangerous where the conditions are met. No private key is needed. No user interaction is described. And the prize, for a privileged impersonation, is host-level control.

There is also reassuring news in the record so far. The Hacker News reports 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, and it is not on CISA's Known Exploited Vulnerabilities list.

That status can change, and it is no substitute for patching. A maximum-severity flaw with a clear fix tends to draw attention quickly, and the window between public disclosure and wider exploitation attempts is often short.

Analysis Note: The most interesting part of this story may be who found it. A community fork, Incus, spotted a flaw in shared code, and the fix then rippled across two projects. Open-source infrastructure is often criticised when a flaw appears — but this is also the model working as intended, with independent eyes catching what the original project missed.

Bottom Line

CVE-2026-112816 is a maximum-severity flaw with a clear, narrow lesson: never treat a public certificate as proof of identity on its own. Canonical has shipped the fixes, and the update path is short.

What to watch next is whether the rollout reaches every channel cleanly, whether any exploitation is reported now that the flaw is public, and whether other projects sharing this certificate-checking pattern audit their own code. For now, the action is simple: check your LXD and MicroCloud versions, refresh the snaps, and verify the result.

FAQ

What is CVE-2026-112816?

It is a critical authentication bypass in Canonical's LXD and MicroCloud, rated CVSS 10.0. It let an attacker impersonate a trusted client by attaching that client's public certificate to their own TLS chain, without holding the private key.

Do I need to worry if I run LXD on a single server?

Probably less than a cluster operator, but do not assume you are safe. A standalone LXD server does not expose its HTTPS API by default, but if the network API was enabled with core.https_address, the attack path is open. Check that setting and your version either way.

Why is a public certificate enough for this attack?

Public certificates are not secret by design — they are meant to be shared. The flaw was that the server checked every certificate in the chain against its trust store, instead of only the leaf certificate whose private key the connection actually proved. That let a public, non-secret certificate stand in for identity.

Which versions fix the flaw?

For LXD snaps: 6.10.1, 5.21.9, 5.0.11 and 4.0.15 on their respective channels. For MicroCloud snaps: 3.4.1 and 2.1.5. Incus users should move to 7.6.0. Always verify the installed version after refreshing.

Has the flaw been used in real attacks?

As reported on November 1, there was no public sign of exploitation. A CISA assessment dated October 30 said the flaw was not known to have been exploited, and it was not on CISA's Known Exploited Vulnerabilities list. That status should be treated as current only as of that reporting, not as a guarantee.

Sources

• The Hacker News — CVSS 10.0 LXD, MicroCloud flaw lets attackers impersonate trusted clients without a private key (November 1, 2026): https://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.html
• SC Media — Critical vulnerability discovered in Canonical LXD and MicroCloud (November 2, 2026): https://www.scworld.com/brief/critical-vulnerability-discovered-in-canonical-lxd-and-microcloud
• Canonical — LXD, the Linux container daemon (background on what LXD is): https://canonical.com/blog/lxd-the-linux-container-daemon
• YouTube — LXD introduction video embedded from Canonical's LXD page (background/context video): https://www.youtube.com/watch?v=U-lXf85Mhno
• Red Eye Eagle News / AI illustration — original illustration for this article