LXD MicroCloud Vulnerability CVE-2026-112816 Explained: CVSS 10.0 Flaw, Fixed Versions and What to Update

Illustrative image: server racks in a data centre. Image: Wikimedia Commons / Fleshas, CC BY-SA 3.0. This is not a photo of LXD or MicroCloud software.

TL;DR — The LXD MicroCloud vulnerability CVE-2026-112816 explained in one line: a CVSS 10.0 certificate-checking flaw lets anyone who can reach the LXD HTTPS API impersonate a trusted client using only that client's public certificate — no private key needed. Canonical fixed it on 29 October 2026; update your snaps now and verify the version afterwards.

📌 KEY HIGHLIGHTS

• The flaw: CVE-2026-112816 — improper certificate validation in LXD's HTTPS listener, rated CVSS 10.0, the maximum score.
• The impact: An unauthenticated attacker can authenticate as any trusted client and, depending on that client's privileges, gain root access to the host machine.
• The fix: LXD 4.0.15, 5.0.11, 5.21.9 and 6.10.1; MicroCloud 2.1.5 and 3.4.1 — all released 29 October 2026.
• The catch: There is no configuration workaround, and the fixed snaps are rolling out progressively — check your version after refreshing.
• Exploitation status: CISA's 30 October assessment records no known exploitation, and the flaw is not in CISA's Known Exploited Vulnerabilities catalogue.

What happened?

On 28 October 2026, Canonical published a security advisory for a critical vulnerability in LXD, its system container and virtual machine manager, and MicroCloud, the platform that clusters several LXD machines together. The flaw, tracked as CVE-2026-112816, was reported to Canonical by the Incus project — the community fork of LXD — and confirmed to affect LXD as well. Canonical thanked Incus developer Stéphane Graber for the collaboration.

The vulnerability was published in the CVE record on 30 October 2026, and covered by The Hacker News on 1 November 2026. It carries a CVSS 4.0 score of 10.0, the highest possible severity, reflecting that it is remotely exploitable, needs no authentication and no user interaction, and can hand over full control of the cluster and the virtual machines it manages.

LXD MicroCloud vulnerability CVE-2026-112816 explained: how the impersonation works

LXD and MicroCloud protect their remote APIs with mutual TLS (mTLS): a remote client proves who it is by presenting a certificate, and the server accepts the client only if that certificate is in its trust store. The bug was in how the server checked the certificate chain the client sent.

The server compared every certificate in the chain 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 — public certificates are not secret — place it behind their own certificate in the chain, and the server would accept them as that trusted client.

MicroCloud has an extra weak point: Canonical says an attacker can intercept the public TLS certificate of a member machine as it joins a cluster, and then authenticate as that joined member. In both cases, the attacker needs two things: network access to the LXD HTTPS API, and the public certificate of a client the server already trusts.

Who is affected?

A standalone LXD server is not exposed by default: it listens only on a local socket unless an administrator deliberately turns on the network API with the core.https_address setting. The risk concentrates on servers and clusters whose HTTPS API is reachable over the network — exactly the setups that remote management and MicroCloud clustering require.

The affected LXD versions and their fixes, per Canonical's advisory, are:

Product / channel	Affected	Fixed version (29 Oct 2026)
LXD 4.0/stable	Up to 4.0.14	4.0.15
LXD 5.0/stable	Up to 5.0.10	5.0.11
LXD 5.21/stable	Up to 5.21.8	5.21.9
LXD 6/stable	Up to 6.9	6.10.1
MicroCloud 2/stable	2.x before 2.1.5	2.1.5
MicroCloud 3/stable	3.x before 3.4.1	3.4.1

Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the fixed releases are the snaps. Users of Incus, the fork that reported the flaw, should move to version 7.6.0, which fixed this flaw along with 17 other security issues.

Illustrative image: a data centre server room. Image: Wikimedia Commons / Christopher Bowns, CC BY-SA 2.0.

Why it matters for readers running their own servers

LXD is a staple of the self-hosting and small-cloud world: it runs system containers and virtual machines on Ubuntu servers, VPS instances and home labs, and MicroCloud turns a handful of machines into a single cluster. That audience includes plenty of Indian developers, students and small hosting providers running Ubuntu servers — there is no India-specific announcement here, but the exposure is the same wherever the HTTPS API faces a network.

The flaw is also a useful lesson in why a 10.0 score does not automatically mean "everyone is hacked". Severity describes what the bug can do; exploitation still needs the two preconditions above. A local-only LXD install with no network API is not reachable this way, while an internet-facing cluster API with a trusted client certificate floating around is the worst case. That distinction is exactly what to check first.

Should you care?

✅ Yes — if you run LXD or MicroCloud with a network-reachable API, update today. The fix is a one-command snap refresh, there is no workaround, and CVE trackers already list proof-of-concept code on GitHub. If your LXD only listens on a local socket, you are not exposed this way — but updating costs nothing, so do it anyway.

What to do now

Canonical's advisory is blunt: all LXD and MicroCloud users should update immediately. On snap installs, run:

sudo snap refresh lxd
sudo snap refresh microcloud

Then verify, don't assume: the fixed point releases are rolling out progressively from the candidate channel to stable, so check the version you actually have with lxd --version or snap list lxd and confirm it matches the fixed version for your channel in the table above. Until you are updated, restrict who can reach the HTTPS API — firewall it to trusted management networks only — since that network access is a required precondition for the attack. There is no configuration fix: the Incus project says the only step short of updating is restricting network access to the listener.

Related reading on the same patch-now pattern: our explainers on the GitLab CVE-2026-97229 flaw added to CISA's exploited list and the Linux kernel TCP flaw CVE-2026-98432 show how quickly maximum-severity Linux flaws move from advisory to active exploitation.

FAQs

What is CVE-2026-112816? It is an improper certificate validation flaw in Canonical LXD's HTTPS listener (and MicroCloud), rated CVSS 10.0. The server checked every certificate in a client's chain against its trust store, even though only the leaf certificate proves ownership of a private key — letting an attacker impersonate any trusted client with just that client's public certificate.

Am I affected by the LXD vulnerability, and how do I check? You are affected if you run LXD 4.0.14, 5.0.10, 5.21.8 or 6.9 (or earlier versions in those branches) with a network-reachable HTTPS API, or MicroCloud before 2.1.5/3.4.1. Check with lxd --version or snap list lxd, and check whether core.https_address is set — a local-socket-only install is not exposed over the network.

How do I fix the LXD MicroCloud vulnerability? Update to the fixed snap for your channel: LXD 4.0.15, 5.0.11, 5.21.9 or 6.10.1, and MicroCloud 2.1.5 or 3.4.1, with sudo snap refresh lxd and sudo snap refresh microcloud. Then confirm the installed version, since the releases are rolling out progressively to stable. Incus users should upgrade to 7.6.0.

Is the LXD flaw being exploited? CISA's assessment dated 30 October 2026 records exploitation as none, and the flaw is not in CISA's Known Exploited Vulnerabilities catalogue. CVE trackers do list proof-of-concept code on GitHub, so the absence of confirmed exploitation is not a reason to delay patching.

Takeaway: A maximum-severity flaw with a one-command fix is the best kind of security emergency — but only if you actually run the command and verify the version. If your LXD API faces a network, refresh your snaps today.

Follow World Tech on TechByCountry for tomorrow's update.

📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.

Sources

• Canonical security advisory: Critical vulnerability found in Canonical LXD and MicroCloud (Ubuntu Discourse, 28 Oct 2026)
• The Hacker News, 1 Nov 2026: CVSS 10.0 LXD, MicroCloud flaw
• CVE record CVE-2026-112816 (published 30 Oct 2026, CISA SSVC assessment)
• Undercode News, 1 Nov 2026: CVE-2026-112816 analysis