What happened

Canonical published a security advisory on 28 October 2026 for a critical authentication bypass in LXD and MicroCloud, tracked as CVE-2026-112816 and rated CVSS 10.0. According to Canonical, the issue was referred to them by the Incus project and confirmed to affect LXD as well.

LXD lets remote clients reach its HTTPS API using mutual TLS. A client is trusted when its certificate sits in the server's trust store. The flaw was in how the server validated the certificate chain presented by the client. The authentication logic compared all peer certificates the client sent against the trust store. However, in a TLS handshake only the leaf certificate proves that the client owns the matching private key. Anything else in the chain is simply what the client chose to attach.

An attacker who can reach the API and who knows the public certificate of an already trusted client can place that certificate behind their own leaf certificate. The server then treats them as the trusted client. Public certificates are not secrets, so the second precondition is weaker than it sounds. In MicroCloud, Canonical notes that an attacker able to intercept the public certificate of a member that is joining the cluster can authenticate as that member afterwards.

Canonical lists fixed snap releases dated 29 October 2026: LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, MicroCloud 3.4.1 and 2.1.5. The Incus project fixed the same issue in version 7.6.0. According to the CISA assessment attached to the CVE record, as reported by The Hacker News, the flaw is not known to be exploited and is not in the KEV catalog.

Why it matters

LXD and MicroCloud often run the infrastructure underneath other workloads: virtual machines, system containers and storage. Impersonating a trusted client gives the same access that client has. Canonical states that, depending on the privilege of the impersonated identity, the attacker may gain root access to the host machine.

The attack needs no private key, no password and no user interaction. It only needs network reachability to the API and a certificate that, by design, is shared with the server and sometimes with other tooling. Environments that expose the API broadly for convenience, for example to a management VLAN that is larger than intended, carry the most risk.

A standalone LXD server does not expose the network API by default. It listens only on a local socket unless an administrator sets core.https_address. That means many installations are not reachable remotely, but clusters and MicroCloud deployments by nature are.

What defenders should check

  • Inventory. List every host running LXD, MicroCloud or Incus, including lab and edge systems. Check snap versions with snap list lxd microcloud.
  • Exposure. On each host run lxc config get core.https_address. An empty value means the network API is not enabled. For MicroCloud members, assume the API is enabled.
  • Reachability. From a normal user network, test whether the API port (8443 by default) is reachable. Compare the result against who actually needs access.
  • Version after refresh. Canonical stated that point releases were still rolling out progressively from candidate to stable. Run the refresh and then confirm the installed version matches a fixed release, rather than assuming it.
  • Trust store. Run lxc config trust list and review every entry, its name, fingerprint and when it was added. Remove anything you cannot tie to a person or system.
  • Internet exposure. Search your own external ranges, for example with Shodan or Censys filters scoped to your organisation and the API port, to find management APIs that should never be public.

Detection ideas

The following are starting points to adapt and test in your environment. They are not production-ready rules. LXD logs and your network telemetry will differ by deployment.

Flag connections to the LXD API from sources outside your management ranges (generic KQL over firewall or flow data):

NetworkConnections
| where DestinationPort == 8443
| where DestinationIP in (lxd_hosts)
| where not(ipv4_is_in_any_range(SourceIP, management_ranges))
| summarize count(), min(Timestamp), max(Timestamp) by SourceIP, DestinationIP

Check LXD logs for activity from unexpected source addresses and for sensitive operations (instance creation, privileged profile changes, new trust entries):

journalctl -u snap.lxd.daemon --since "2026-10-01" | grep -Ei "trust|certificate|api"
lxc operation list
lxc config trust list

Compare the same client certificate fingerprint appearing from multiple unrelated source IPs. A legitimate administrator or automation tool normally connects from a small, stable set of addresses. Use your proxy or flow logs to correlate fingerprints with sources where you have TLS visibility.

Investigation

If an API was reachable from untrusted networks before patching, treat the host as potentially affected and collect evidence before changing anything further:

  • Export the trust store (lxc config trust list) and note any entries added recently.
  • Preserve LXD daemon logs, the journal, and firewall or flow logs covering the exposure window.
  • List instances, profiles, images, storage volumes and networks and compare them against your change records. Look for new privileged containers, profiles that mount host paths, and instances you did not create.
  • On the host, review shell history, new SSH keys, new users, cron entries and systemd units, since a privileged container can be used to write to the host filesystem.
  • Capture the process list and network connections of the host and of any suspicious instance.
  • For MicroCloud, review when members joined the cluster and whether the join traffic crossed networks you do not control.

If you find signs of misuse, treat credentials, certificates and secrets stored on the host as exposed and rotate them. Our team can help with incident response and a compromise assessment when you need an independent review.

Mitigation

  • Update. Run sudo snap refresh lxd and sudo snap refresh microcloud, then verify the version against Canonical's table. Incus users should move to 7.6.0.
  • Restrict network access. Canonical's advisory gives no workaround for LXD. Per the Incus project, there is no configuration fix, and limiting who can reach the listener is the way to reduce risk until you update.
  • Put the API behind firewall rules or a management network that only trusted administrators and automation can reach. Do not expose it to the internet.
  • Review the trust store and remove stale or unknown clients. Rotate client certificates for privileged identities if you suspect exposure.
  • Add the API port to your regular external attack surface scans so a future misconfiguration is caught early.

Sources: Canonical LXD security advisory (discourse.ubuntu.com), the GitHub advisory GHSA-99jp-jwmc-65p4, and reporting by The Hacker News.