Canonical published a critical advisory on Oct 28 for CVE-2026-112816 (CVSS 4.0 base score 10.0, critical), an authentication bypass in the HTTPS listener of LXD and MicroCloud. The issue was referred by the Incus project, the community fork of LXD.

• Bug: remote API authentication over mutual TLS compared all peer certificates the client sent with trust-store entries. Only the leaf certificate proves the client holds the private key, so an attacker could put a trusted client's public certificate in the chain as an intermediate and be accepted as that client.
• Impact: full access to the cluster and its managed instances as the impersonated identity; Canonical says that can mean root on the host for privileged users. In MicroCloud, an attacker who intercepts a joining member's public certificate can then authenticate as that member.
• Exposure: requires network reach to the LXD/MicroCloud HTTPS API. A standalone LXD only listens on the local socket unless core.https_address is set; clusters and MicroCloud expose it by design.
• Affected / fixed (snaps): 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 (all released Oct 29). Incus fixed the same flaw in 7.6.0.
• Exploitation: not on CISA KEV; CISA's SSVC assessment in the CVE record (Oct 30) lists exploitation as none, automatable yes, technical impact total.

What to do: run sudo snap refresh lxd and sudo snap refresh microcloud, then confirm the version actually installed (Canonical said the point releases were rolling out progressively from candidate to stable). Until patched, restrict who can reach the API port (firewall to admin hosts only); there is no config workaround. After patching, review the trust store (lxc config trust list) and API logs for unexpected client activity.