---
title: "LXD and MicroCloud mTLS Auth Bypass CVE-2026-112816"
url: https://erroneo.us/security/briefs/lxd-microcloud-mtls-chain-auth-bypass-cve-2026-112816/
description: "LXD's HTTPS API trusted any cert in a client chain, letting attackers impersonate trusted clients. Fixed in LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15."
type: security-brief
section: "Security Digest"
date_published: 2026-10-29
date_modified: 2026-10-29
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Check exposure"
cves: ["CVE-2026-112816"]
severity: "critical"
exploited: "none-known"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

# LXD and MicroCloud mTLS Auth Bypass CVE-2026-112816

**Verdict: Check exposure.** Only LXD hosts with the HTTPS API enabled, which includes every cluster and MicroCloud, are at risk, but there the bug is a full authentication bypass to root, so refresh the snap this week.

- **Who must act:** Operators of LXD servers with core.https_address set, LXD clusters and MicroCloud deployments, especially where the API is reachable from shared or untrusted networks.
- **Who can relax:** Single-host LXD installs that use only the local Unix socket (the default) and have never set core.https_address.
- **Affected:** LXD 6.x before 6.10.1; LXD 5.21 LTS before 5.21.9; LXD 5.0 LTS before 5.0.11; LXD 4.0 LTS before 4.0.15; MicroCloud 2.x before 2.1.5 and 3.x before 3.4.1
- **Fixed:** LXD 6.10.1 (6/stable); LXD 5.21.9 (5.21/stable); LXD 5.0.11 (5.0/stable); LXD 4.0.15 (4.0/stable); MicroCloud 2.1.5 (2/stable) and 3.4.1 (3/stable)
- **CVEs:** CVE-2026-112816
- **CISA KEV:** no · **Exploitation:** No known exploitation

## What to do

1. Check whether the HTTPS API is on with lxc config get core.https_address; an empty result means only the Unix socket is in use.
2. Check the installed version with snap list lxd and lxc version, then run sudo snap refresh lxd (and sudo snap refresh microcloud).
3. If the fixed revision has not reached your channel yet, restrict port 8443 (or your configured port) to management networks with a host or network firewall until it does.
4. After patching, review lxc config trust list and remove clients you no longer need, since each trusted certificate was a usable identity for an attacker.
5. Update every member of a cluster; a single unpatched member keeps the bypass available.

### How to check if you are affected

- Review lxc config trust list for entries you did not add and for unexpected new certificates added after October 2026.
- Review LXD daemon logs (journalctl -u snap.lxd.daemon) and lifecycle events (lxc monitor --type=lifecycle) for API actions from unfamiliar source addresses or at unusual times.
- Look for unexpected instances, images, profiles, storage volumes or devices (especially disk devices mapping host paths) created on exposed servers.

## What happened

Canonical has fixed a critical authentication bypass in LXD, its system container and virtual machine manager, and in MicroCloud, which deploys LXD clusters. In its [advisory](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557), Canonical says the flaw "allows an attacker that is able to reach the LXD HTTPS API to authenticate as any trusted TLS client" whose public certificate the attacker has. The Incus project, a community fork of LXD, reported it and confirmed that it affects LXD. Fixed releases went out on October 29, 2026, and the [CVE record](https://www.cve.org/CVERecord?id=CVE-2026-112816) was published on October 30. Canonical, acting as CNA, gave it a CVSS 4.0 score of 10.0.

The root cause is a mutual-TLS mistake. LXD clients authenticate by presenting a client certificate, and LXD admits them if that certificate is in its trust store. The vulnerable code checked every certificate in the client's chain against the trust store. As Canonical puts it, though, "only the leaf certificate proves ownership of the signing key." An attacker can put a trusted client's public certificate into the chain as an intermediate, sign the handshake with a leaf key the attacker owns, and be accepted as that trusted client. A public certificate is not a secret. It is often copied into scripts, CI configuration and documentation, and any trusted user can read it from LXD's trust list.

MicroCloud has a related problem. During cluster join, an attacker who can intercept a joining member's public certificate can then authenticate as that member. Canonical says that, depending on the identity impersonated, an attacker "may gain root access to the host." With LXD admin rights, that is a short step.

## Who is affected

- LXD 6.x before 6.10.1, 5.21 LTS before 5.21.9, 5.0 LTS before 5.0.11, and 4.0 LTS before 4.0.15. The CVE record names specific starting versions (4.0.14, 5.0.10, 5.21.8, 6.9.0), but Canonical's advisory does not, so treat anything older than the fix on your track as affected.
- MicroCloud before 2.1.5 (2/stable) and 3.4.1 (3/stable).
- Only servers where the HTTPS API is listening. The [LXD documentation](https://canonical.com/lxd/docs/latest/howto/server_expose/) says that by default "LXD can be used only by local users through a Unix socket and is not accessible over the network." You turn the HTTPS API on with `core.https_address`. Clustering and MicroCloud require it.

## Do you really need to act?

On a laptop or single server that uses LXD only through the local socket, this bug is not reachable, so update on your normal schedule. On a host where `core.https_address` is set, it is a complete authentication bypass that needs no password, token or private key, only a certificate that was never meant to be secret. Exposure depends on who can reach port 8443 (the usual port). If the API is open to the internet or to a shared network such as a lab, a colocation VLAN or a tenant network, treat this as urgent. If it is reachable only from a locked-down management network, you have a little more time, but do not wait for the next maintenance cycle.

As of November 2, Canonical has not reported exploitation, the CVE is not in CISA's KEV catalog, and we found no public exploit. The GitHub advisory that the CVE record links to (GHSA-99jp-jwmc-65p4) was not publicly visible when we checked. The technique is simple to describe, though, and now that the fix is public, anyone can study it.

## What to do now

1. Check exposure: `lxc config get core.https_address`. An empty value means the HTTPS API is off. Also check `ss -ltnp | grep lxd`.
2. Check versions with `snap list lxd` and `lxc version`, then update with `sudo snap refresh lxd` and, where used, `sudo snap refresh microcloud`.
3. Canonical notes that point releases are rolling out progressively from candidate to stable. If `snap refresh` does not yet bring the fixed version, restrict the API port to management addresses with a firewall until it does.
4. Update every cluster member. One unpatched member still accepts the forged chain.
5. Prune `lxc config trust list`. Every trusted certificate was an identity an attacker could have borrowed.

## How to tell if you were hit

LXD sees an attacker as a legitimate trusted client, so look for actions rather than failed logins. Review `journalctl -u snap.lxd.daemon` and lifecycle events from `lxc monitor --type=lifecycle` (or your log forwarding) for API calls from unfamiliar addresses. Check for instances, images, profiles or devices you did not create, especially `disk` devices that map host paths into containers. Also check for new entries in the trust store.

## Timeline

- Oct 28, 2026 — Canonical's security advisory for LXD and MicroCloud is posted.
- Oct 29, 2026 — Fixed LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15 and MicroCloud 2.1.5 and 3.4.1 reach the stable snap channels.
- Oct 30, 2026 — CVE-2026-112816 is published with a CVSS 4.0 score of 10.0.

## Sources

1. [Canonical (Ubuntu Discourse) — Security advisory: critical vulnerability found in Canonical LXD and MicroCloud](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557)
2. [CVE record — CVE-2026-112816](https://www.cve.org/CVERecord?id=CVE-2026-112816)
3. [Canonical (Ubuntu Discourse) — LXD 6.10.1 LTS has been released](https://discourse.ubuntu.com/t/lxd-6-10-1-lts-has-been-released/90024)
4. [LXD documentation — How to expose LXD to the network](https://canonical.com/lxd/docs/latest/howto/server_expose/)
5. [CVE Project — CVE-2026-112816 JSON record](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/112xxx/CVE-2026-112816.json)

---
Source page: https://erroneo.us/security/briefs/lxd-microcloud-mtls-chain-auth-bypass-cve-2026-112816/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt