VULNpocalypse
CriticalVulnerabilityPatch available

Canonical LXD and MicroCloud CVE-2026-112816: unverified mTLS client chain lets anyone impersonate a trusted client

LXD and MicroCloud accepted a trusted public certificate anywhere in a client’s chain, enabling impersonation. Refresh to LXD 6.10.1, 5.21.9, 5.0.11 or 4.0.15.

Published
Updated
Fixed in
LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15; MicroCloud 3.4.1, 2.1.5; Incus 7.6.0
Exploitation
No. CISA’s assessment on the CVE record (30 October) says none; no public exploit

Live scores

CVE-2026-112816
EPSS
0.003
low predicted chance of attack
VEDAS
0.508
some exploit evidence
On CISA KEV
Not listed
Detection rule
None yet

What happened

LXD authenticates remote API clients with mutual TLS. A TLS handshake only proves the client holds the private key for the first (leaf) certificate it sends. LXD checked every certificate in the client’s chain against its trust store. So an attacker could put a trusted client’s public certificate behind their own as a fake intermediate and be treated as that client (Ubuntu Discourse).

Public certificates are not secret. The Incus advisory explains how easy they are to get: a server’s certificate comes back in every TLS handshake, and any trusted client can read other clients’ certificates through the certificates API (Incus). In MicroCloud, an attacker who captures a joining member’s public certificate can authenticate as that member (Ubuntu Discourse).

The result is full access to the cluster and its virtual machines and, depending on the impersonated client’s privileges, root on the host. Canonical’s CVE record scores it CVSS 4.0 10.0 (CVE record).

Stephane Graber of Incus, the community fork of LXD, reported the bug, and the Incus project referred it to Canonical (CVE record). Incus fixed it in 7.6.0 and says it has been there “since the initial release” (Incus). Canonical published its advisory on 28 October, and the fixed snaps are dated 29 October (Ubuntu Discourse).

No exploitation is known. CISA’s assessment on the CVE record, dated 30 October, says exploitation is “none” (CVE record). No public exploit has been published (The Hacker News).

Am I affected?

The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each up to the next fixed release (CVE record). Older LXD releases are not listed. Ubuntu’s own archive packages of LXD are listed as not affected or not shipped, so the fix is in the snaps (The Hacker News).

The attacker needs to reach the HTTPS API. A standalone LXD server listens only on a local Unix socket unless core.https_address is set (The Hacker News). Clusters and MicroCloud always use the network API.

bash
# Installed versions and channels
snap list lxd microcloud

# Is the network API on? Empty output means local socket only
lxc config get core.https_address

# Which client certificates are trusted (the identities an attacker could borrow)
lxc config trust list

Incus users can check with incus version; anything before 7.6.0 is affected (Incus).

What to do now

  1. Refresh the snaps and check the version afterwards. Fixed versions by channel: LXD 6/stable 6.10.1, 5.21/stable 5.21.9, 5.0/stable 5.0.11, 4.0/stable 4.0.15; MicroCloud 3/stable 3.4.1, 2/stable 2.1.5. Canonical says the point releases are rolling from candidate to stable, so a refresh may not land the fix at once (Ubuntu Discourse):
bash
sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud
  1. Restrict who can reach the LXD API port until every node is fixed. Canonical gives no workaround; Incus says there is no configuration fix and network restriction is the only interim step (Incus).
  2. If the API was not meant to be remote, unset it with lxc config unset core.https_address on standalone hosts.
  3. Incus: upgrade to 7.6.0. It fixes this flaw along with 17 other security issues (The Hacker News). The Incus advisory notes the flaw also let a client renew or delete any trust store entry through self-service paths, so review incus config trust list for entries you did not add (Incus).

Sources