Canonical fixes CVSS 10.0 LXD and MicroCloud flaw that impersonates trusted clients

Canonical released fixes on Oct. 29, 2026, for CVE-2026-112816, a CVSS 10.0 flaw in LXD and MicroCloud that lets an attacker log in as a trusted client without possessing the private key. The CVSS 4.0 vector maximizes all 11 base metrics, producing a score of 10. Hamer Intelligence Services disclosed the flaw around 09:06 UTC on Nov. 1, 2026.

The CVE record flags LXD releases 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected ahead of the fixed version, and treats all other versions as unaffected by default. The fixes include LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 2.1.5 and 3.4.1. SiTech listed the fixed releases by snap channel as 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 and MicroCloud 2/stable 2.1.5.

Exploitation needs network access to the LXD HTTPS API plus the trusted client’s public certificate. The server checks each client certificate against its trust store, while TLS, the protocol that encrypts web connections, checks only the first certificate in the chain. Canonical said capturing a joining member’s public certificate lets an attacker later authenticate as that member. The CVE record cites CWE-295, improper certificate validation, in the HTTPS listener.

An attacker can append a trusted client’s public certificate to their own certificate, and the server lets the attacker act as that trusted client. That public certificate is not secret. Once authenticated, the attacker can act as the client and reach the cluster and its virtual machines. Canonical said that, based on the victim’s privileges, the attacker might gain root access on the host.

The CVE Program record credits Stéphane Graber with originally finding and disclosing the flaw. Incus is a community fork of LXD; it reported the flaw, and Canonical confirmed the flaw affected LXD as well. P.K. Sharma reports that the Incus fix commit from Oct. 29, 2026, says the listener only proves the client holds the first certificate in its chain and that every trust store check now matches just the first peer certificate. Canonical’s documentation describes LXD as local-only by default, reached through a Unix socket, with no network access.

MicroCloud links LXD machines together into one cluster. A standalone LXD server does not expose the HTTPS API by default and instead listens on a local socket, and an administrator switches on the network API with the core.https_address setting. Restricting access to the HTTPS API reduces risk until administrators install the fix. Hamer Intelligence Services said LXD and MicroCloud see wide deployment in Ubuntu-based private and edge clouds.

CVE Brief said the flaw can remove confidentiality, integrity and availability across an entire LXD cluster and its virtual machines, and can give total control over infrastructure, leading to serious data theft or complete service disruption. The CVE Brief analyst said attackers can automate the flaw, granting administrative-level access to the virtualized infrastructure.

Hamer Intelligence Services said public-sector platforms, smaller cloud providers, telecommunications companies and financial institutions that use Ubuntu for virtualization face risk from the flaw. An intruder could reach virtual machines, containers, storage and potentially the physical host, and could use compromised hosts to move into neighboring networks. The attacker could also start rogue workloads, copy data at scale or change logs.

Hamer Intelligence Services said the flaw could interest advanced persistent threats and state-aligned actors trying to slip into regional cloud hubs and edge nodes to watch military, energy and critical infrastructure. The firm also said the attack uses ordinary-looking certificates and API calls, making it hard to spot with ordinary perimeter defenses.

A U.S. CISA assessment dated Oct. 30 says no one is known to be exploiting the flaw, and CISA’s Known Exploited Vulnerabilities list does not include CVE-2026-112816. There is no public evidence of an attack using the flaw, and researchers have not published a working exploit. The CVE record leaves exploit maturity at NOT_DEFINED and CVE Brief lists public exploit availability as unknown. P.K. Sharma reports that CISA is the only independent party on the record, through its assessment in the CVE record.

The Ubuntu archive does not ship the affected LXD packages, so Canonical supplies the fixes as snaps. The Ubuntu CVE page rates this issue Medium, and the archive lxd package shows Not affected for Ubuntu 16.04, 18.04 and 20.04 and Not in release beginning at 22.04. P.K. Sharma reports that the CVE record itself names affected LXD lines in four separate tracks but omits any MicroCloud product, even though Canonical filed the record as the numbering authority. Neither Canonical’s advisory nor the CVE record lists LXD 3.0 or MicroCloud 1, and neither says whether they are vulnerable.

Canonical said the fixed LXD point releases were still traveling from candidate to stable when the advisory came out, so administrators should check the installed version after refreshing. P.K. Sharma reports that every fixed version had reached its stable snap channel by 10:53 GMT on Nov. 1, that the store showed Nov. 1 as the stable release date for the 4.0, 5.0 and 5.21 tracks, and that the 6.10.1 build in 6/stable has shared its store revision with the 6/candidate build since Oct. 22.

Incus users should move to 7.6.0, which fixed this flaw along with 17 other security issues. P.K. Sharma reports that the Incus 7.6 release post covers 18 security issues, rated eight critical, five high and five medium, and that the Incus advisory GHSA-xg75-xf37-cph9, published Oct. 29, 2026, calls the flaw critical and marks every version below v7.6.0 as vulnerable. The advisory describes wider effects than Canonical’s, including logins as any trusted client, internal cluster access, renewal or deletion of trust store entries, host-to-VM agent connections and authorization scriptlet decisions, and the release post offers no workarounds.

Administrators should run sudo snap refresh lxd, and should also run sudo snap refresh microcloud, on snap installs. Canonical’s advisory offers no temporary workaround for LXD, and the Incus project said there is no configuration fix, pointing administrators to network-level restrictions on the listener instead.

CVE Brief says to block network access to the LXD HTTPS listener from all but known, trusted IP addresses with firewalls or security groups, and to check system and cluster access logs for unusual authentication patterns or connections from unknown certificate chains. The Incus project said: “Restrict network access to the HTTPS listener to trusted hosts. There is no configuration based workaround.”