Home » Security » LXD and MicroCloud Flaw Lets Attackers Pose as Trusted Clients

LXD and MicroCloud Flaw Lets Attackers Pose as Trusted Clients

Published 2026-11-02 | Security

Banner showing a certificate with a mask over it beside the text LXD and MicroCloud flaw lets attackers pose as trusted clients

Short answer: LXD, MicroCloud and Incus, the tools many people use to run containers and virtual machines on Linux, had a login bug that let an attacker pretend to be any trusted client. All the attacker needed was that client's public certificate, which is not secret. Canonical fixed it on October 29, 2026 as CVE-2026-112816. If you run any of these with the network API turned on, run sudo snap refresh lxd (and sudo snap refresh microcloud if you use it) today.

The key facts

Item Detail
CVE CVE-2026-112816
Severity CVSS 10.0, the maximum, in the Incus advisory
Affected LXD 4.0, 5.0, 5.21 and 6.x before the fixes below, MicroCloud, Incus before 7.6.0
Fixed LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15
Fixed MicroCloud 3.4.1, 2.1.5
Fixed Incus 7.6.0
Found by Stéphane Graber of the Incus project, who passed it to Canonical
Attacks seen None reported

What went wrong

LXD lets remote clients log in with mutual TLS. In plain terms, the client shows a certificate, and the server checks it against a list of certificates it trusts.

The catch is that a client can send a chain of several certificates, not just one. The TLS handshake only proves the client owns the private key for the first one, called the leaf. LXD, though, compared every certificate in the chain against its trust list.

Canonical's advisory spells out the result: an attacker could authenticate "as another identity by placing their trusted public TLS certificate as an intermediary certificate in the chain." So you make your own certificate, tack a trusted admin's public certificate onto the end, and the server lets you in as that admin.

The Incus advisory adds that this has been true "since the initial release" of the code, and that public certificates are easy to collect. Servers hand theirs out in every TLS handshake, which means adding a cluster member's certificate could give access to internal cluster traffic.

Canonical says that, depending on who the attacker impersonates, they "may gain root access to the host machine."

Step 1: check whether your API is reachable

The bug lives in the HTTPS API. Check whether yours is on:

lxc config get core.https_address

An empty result means LXD only listens on its local socket, so a remote attacker cannot reach it this way. Any address, such as [::]:8443, means it is listening on the network. Clusters and MicroCloud always use the network API.

Step 2: check your version

snap list lxd microcloud

Compare the version column with the fixed versions in the table above. Incus users can run incus version.

Step 3: update

For snap installs:

sudo snap refresh lxd
sudo snap refresh microcloud

Canonical notes the fixed releases were rolling out gradually from the candidate channel to stable, so if the refresh does not pull a fixed version yet, try again later or check snap info lxd for your track. Incus users should move to 7.6.0 or later through their usual package source.

Step 4: limit network access until you can patch

Neither project offers a setting that switches the bug off. The Incus team's advice is to "restrict network access to the HTTPS listener to trusted hosts." A firewall rule that only allows your admin machines to reach port 8443 is a reasonable stopgap. It is not a fix.

Step 5: review your trust list afterwards

Once patched, look at who your server trusts:

lxc config trust list

Remove anything you do not recognise. If your API was exposed to the internet before the fix, check instance and host logs for activity you did not expect.

Common mistakes

  • Assuming a client certificate is a secret. The public part is designed to be shared, which is exactly why this bug was so serious.
  • Patching LXD but forgetting MicroCloud, or the other way round. They are separate snaps.
  • Relying on a firewall rule and never updating. The rule only narrows who can try.
  • Treating Ubuntu's "Medium" priority label as a CVSS score. It is a different scale, and the Incus advisory rates the bug 10.0.
  • Reading "no attacks reported" as "safe to wait." The trick is simple to describe, now that it is public.

Sources

Frequently Asked Questions

Which LXD versions fix CVE-2026-112816?

LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, all released on October 29, 2026. MicroCloud is fixed in 3.4.1 and 2.1.5, and Incus in 7.6.0.

Is my LXD server exposed if I never turned on the network API?

Much less so. The attack goes through the HTTPS API, and a standalone LXD server only listens on a local socket unless an administrator sets core.https_address. Clusters and MicroCloud always use the network API, so update those first.

Has the LXD certificate flaw been exploited?

Neither Canonical nor the Incus project has reported attacks. That can change, and the fix is a simple snap refresh, so there is little reason to wait.

Found a mistake or still stuck? Contact us. See how we write and check these guides in our editorial policy, or read about DocumentGuy.