CVSS 10.0 LXD MicroCloud Flaw: Client Impersonation

What happened

A critical flaw in Canonical's LXD and MicroCloud lets an attacker log in as a trusted client without that client's private key. The attacker needs network access to the HTTPS API and the trusted client's public certificate. The Hacker News reported it on Nov 1, 2026.

The flaw is tracked as CVE-2026-112816 and scores the maximum CVSS 10.0. If the impersonated account is privileged, the attacker could gain "root access to the host machine," Canonical said.

Why the check failed

LXD and MicroCloud use mutual TLS. The client shows a certificate, and the server accepts it if that certificate is in its trust store.

The server 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, the leaf. The rest of the chain is whatever the client attaches.

So an attacker can take a trusted client's public certificate, which is not secret, and attach it behind their own. The server then accepts them as that client.

Who is affected

Exploitation 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 enables the network API with core.https_address.

MicroCloud has a specific weak point. Canonical said an attacker who captures 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 below.

Ubuntu's own archive packages of LXD are listed as not affected or not shipped. The fixed releases are the snaps.

The Incus project, a community fork of LXD, reported the bug, and Canonical confirmed LXD was affected too. Incus fixed it in 7.6.0.

How serious it is and whether it is exploited

The score is the maximum, but the real risk depends on exposure. A server with no network API and no reachable listener is far harder to attack than a cluster whose API sits on a broad network.

There is no public sign of attacks. 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.

Clusters deserve the most attention. Joining a member exposes its public certificate, and a trusted member can reach the cluster and its virtual machines.

Check your exposure

Start with the version, then see whether the network API is on.

snap list lxd microcloud
lxc config get core.https_address
ss -tlnp | grep -i lxd

An empty core.https_address on a standalone server means the network API is off. A value means the network API is reachable, so restrict who can connect to it until you patch.

Next, see which identities the server trusts. Each one is a certificate an attacker could try to reuse.

lxc config trust list
lxc cluster list

Remove entries for clients you no longer use. Fewer trusted certificates means fewer ways in.

Patch and mitigate

Update first. On a snap install, run these commands.

sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud

Canonical said the fixed LXD point releases were still rolling out from candidate to stable at the time of its advisory. Compare the version in the last command with the table above instead of assuming the fix arrived.

Canonical's advisory gives no temporary workaround for LXD. Because the attack needs network access, limiting who can reach the API reduces risk until you update. The Incus project said there is no configuration fix, and the only step is to restrict network access to the listener.

Incus users should move to 7.6.0, which fixed this flaw and 17 other security issues.

Worked example: a three-node MicroCloud cluster

Say you run three MicroCloud members on one internal network. Here is a sensible order.

1. Run snap list lxd microcloud on each node and note the versions.

2. Limit access to the API listener to the three node addresses and your admin hosts.

3. Run sudo snap refresh lxd and sudo snap refresh microcloud on each node.

4. Re-run snap list and confirm the fixed versions, such as 3.4.1 for the 3/stable channel.

5. Run lxc config trust list and remove clients that no longer need access.

6. Avoid joining new members over untrusted networks until every node is patched.

Virtualization hosts are high-value targets. See also China-linked hackers exploiting a VMware ESX zero-day to reduce audit trail visibility.

What learners can take from it

This bug is a good lesson in what mutual TLS actually proves. A valid handshake proves the client holds the key for the leaf certificate, nothing more. Checking the wrong part of a certificate chain turns a public file into a login. Cloud and Linux administration exams commonly test trust stores, certificate validation and limiting API exposure. If you want structured practice on Linux hardening, the CompTIA Linux+ XK0-005 voucher is a fitting target.

For more security news and study paths, browse our Cybersecurity certifications.

Sources

• CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key (The Hacker News)