LXD and MicroCloud Fix CVE-2026-112816, Rated CVSS 10.0, Which Let a Client Pose as a Trusted Client Without Its Private Key; Incus Also Fixes It

Overview

Canonical has released fixed versions of LXD and MicroCloud for CVE-2026-112816, a certificate-validation flaw in the LXD HTTPS listener. The NVD entry says the flaw “allows an unauthenticated attacker to authenticate as any trusted client and gain full access to the cluster and managed virtual machines via a crafted certificate chain.” The Hacker News adds the practical conditions: the attacker has to reach the HTTPS API over the network and have the public certificate of a trusted client.

The Incus project, which The Hacker News says “began as a community fork of LXD,” published its own advisory for the same flaw and fixed it in Incus 7.6.0.

How the flaw works

According to the LXD security advisory on GitHub, the HTTPS listener requests client certificates without verifying them, so the TLS handshake only proves that the client holds the private key of the first certificate in the chain it presents. The advisory says the authentication and certificate-ownership checks compared every certificate in the presented chain against the trust store, so a client could authenticate as any trusted certificate by appending that certificate’s public part to its own chain, without holding the matching private key. The advisory states: “This has been the case since the initial release.”

The advisory lists these consequences:

• Any client able to reach the listener can authenticate as any trusted client, metrics or server certificate for which it has the public certificate, including as a cluster member.
• Server certificates are returned by every TLS handshake, so no prior access is needed to obtain one. Appending the server’s own certificate grants access to the database gateway, and on a cluster appending another member’s certificate grants internal cluster access.
• The flaw lets a client renew or delete any trust store entry through the self-service paths, and it affects the authentication of the agent connection between the host and virtual machines.

If the impersonated account is privileged, the attacker could gain “root access to the host machine,” Canonical said, as reported by The Hacker News. For MicroCloud, the same report says Canonical identified a specific weak point: an attacker who can capture a member’s public certificate as it joins the cluster can then log in as that member.

Affected and fixed versions

The NVD entry lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before 4.0.15, 5.0.11, 5.21.9 and 6.10.1 respectively. The Hacker News lists the fixed snap versions Canonical gave: LXD 6.10.1 (6/stable), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable) and 4.0.15 (4.0/stable), and MicroCloud 3.4.1 (3/stable) and 2.1.5 (2/stable).

GitHub’s release listings give these publication times, in UTC: lxd-6.10.1 on October 28 at 12:58, lxd-5.21.9 on October 29 at 14:33, lxd-5.0.11 on October 29 at 21:27 and lxd-4.0.15 on October 29 at 21:26.

The GitHub advisory’s patched-versions field reads “4.0.15, 5.0.11, 5.21.9, 6.10.0, 6.10.1,” which includes 6.10.0; the CVE description names 6.10.1 as the fix for the 6.9 line. None of the cited sources explains the difference.

The Hacker News also reports that a standalone LXD server does not expose the API by default, listening only on a local socket unless an administrator enables the network API with the core.https_address setting. It says Canonical stated that the fixed LXD point releases were still rolling out from the candidate channel to stable at the time of its advisory, and it advises checking the installed version after refreshing.

Ubuntu packages

The same report says Ubuntu’s own archive packages of LXD are listed as not affected or not shipped, so the fixed releases are the snaps. The Ubuntu security tracker shows the lxd package as “Not in release” for Ubuntu 22.04 LTS through 26.10 and “Not affected” for 20.04 LTS, 18.04 LTS and 16.04 LTS. It lists an Ubuntu priority of Medium alongside a CVSS v4.0 base score of 10.0.

Severity scores and exploitation status

The CVE record, published by Canonical as the CVE numbering authority, carries a CVSS v4.0 base score of 10 (Critical) with the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. The GitHub advisory carries a CVSS v3.1 score of 10 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

The CVE record also includes an assessment entered by CISA’s Vulnrichment program, timestamped October 30 (UTC), with Exploitation set to “none,” Automatable to “yes” and Technical Impact to “total.” The Hacker News, in an article published on November 1 (UTC), says the flaw is not on CISA’s Known Exploited Vulnerabilities list and that no working exploit had been published. None of the cited sources reports exploitation of the flaw.

Incus and the workaround

The Incus advisory was published on GitHub on October 29 at 22:17 UTC, rated critical, and lists Incus versions before v7.6.0 as vulnerable. The Incus 7.6.0 release was published on October 30 at 01:50 UTC. The Hacker News says 7.6.0 fixed this flaw along with 17 other security issues. The Incus advisory carried no CVE identifier in GitHub’s data when the Herald checked on November 7. It adds that the unverified presented chain was also passed to the authorization scriptlet, so a client could feed it attacker-chosen certificates to influence scriptlet-based authorization decisions.

Both the LXD and Incus advisories give the same workaround guidance: restrict network access to the HTTPS listener to trusted hosts, and “There is no configuration based workaround.”

What we don’t know

• How many LXD, MicroCloud or Incus deployments expose the HTTPS API to untrusted networks is not stated in the cited sources.
• The cited sources do not explain why the GitHub advisory lists 6.10.0 as patched while the CVE description names 6.10.1.
• The Herald has not independently tested the flaw or the fixed releases.