Critical LXD and MicroCloud Flaw: What to Check Now

A flaw in LXD and MicroCloud, Canonical's container and virtual machine manager, lets an attacker who can reach its API over the network pose as a trusted client without holding that client's key. Canonical shipped fixes on October 29, 2026. It affects servers and VPS hosts that run LXD with the API open.

What we know

  • What it is: LXD checked client certificates against its trust store, but it treated the whole certificate chain as proof, while the connection only proves the client holds the key for the first one. A trusted client's public certificate was enough to impersonate it, according to Canonical's October 28 advisory.
  • Who can attack: per Canonical, someone «able to reach the LXD HTTPS API» who also has a trusted client's public certificate. In MicroCloud, the path is intercepting a member's public certificate while it joins the cluster. Depending on the impersonated identity's privileges, Canonical says it could lead to root access on the host.
  • Severity: the Incus project, which found the bug and alerted Canonical, scores it 10 out of 10 (CVSS 3.1) in its GitHub advisory. Canonical calls it critical. Ubuntu's CVE page gives it medium priority for its traditional packages; LXD now ships as a snap.
  • Fixed versions (October 29): LXD 6.10.1 (6/stable channel), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable) and 4.0.15 (4.0/stable); MicroCloud 3.4.1 (3/stable) and 2.1.5 (2/stable). Incus is fixed in 7.6.0.
  • Gradual rollout: Canonical warns that the new LXD releases move progressively from candidate to stable, so the update may not show up right away.
  • Attacks: according to The Hacker News, the CVE record carries an October 30 CISA assessment with no known exploitation, and no public exploit exists.

What changes and what doesn't

  • It changes things for anyone running LXD or MicroCloud with the API listening on the network: a cluster, a remotely managed server, or a provider that hands out containers.
  • It matters less if you use LXD locally only: the HTTPS API is not network-facing unless you configure it. Updating is still wise.
  • Nothing changes if your site is on shared hosting or on a VPS without LXD.
  • Your site's code is not involved: WordPress, Drupal, PHP and plugins have nothing to do with it; this is the layer that creates and isolates containers.

How to tell if it affects you

  1. Check whether you use LXD. On the server, `snap list lxd` (or `snap list microcloud`) shows the version and channel. If it says it is not installed, this flaw is not yours.
  2. Compare the version with the fixed one for your channel: 6.10.1, 5.21.9, 5.0.11 or 4.0.15 for LXD; 3.4.1 or 2.1.5 for MicroCloud.
  3. See whether the API is network-facing with `lxc config get core.https_address`. Empty output means LXD listens locally only. An address and port (8443 by default) means the API is reachable, and the fix is more urgent.
  4. Update with `sudo snap refresh lxd` and, if you use it, `sudo snap refresh microcloud`. If the fixed version hasn't arrived yet, try again in a few hours.
  5. In the meantime, lock down access. The Incus advisory says no configuration setting prevents the flaw and recommends restricting network access to the API to trusted hosts: in practice, a firewall rule for that port.
  6. If a provider runs your VPS, ask them: «Do you use LXD or MicroCloud to run the machines? Have you applied the fix for CVE-2026-112816?». On shared hosting, that question is all you need.

Related: Critical Linux Kernel Flaw: What to Check on Your Server

Sources

Updates: if real-world exploitation is confirmed or Canonical changes the fixed versions, it will be added here with a link.