The flaw carries a maximum CVSS score of 10.0 and is tracked as CVE-2026-112816, a vulnerability that allowed an attacker to log in as a trusted client to Canonical’s LXD and MicroCloud without possessing that client’s private key.
How the LXD and MicroCloud certificate check fails
LXD and MicroCloud expose an HTTPS API that can use mutual TLS: the client presents a certificate and the server checks that certificate against a trust store of accepted identities. The vulnerability arose because the server compared every certificate the client sent against the trust store, while a TLS connection actually proves ownership of the private key only for the first certificate in the chain (the leaf certificate). An attacker could present their own leaf certificate and append a trusted client’s public certificate further down the chain; because the server checked all presented certificates, it would accept the trusted identity even though the attacker did not hold the trusted client’s private key.
Once authenticated in this way, the attacker would “act as that client, with access to the cluster and its virtual machines.” Canonical warned that if the impersonated account is privileged, an attacker could gain “root access to the host machine.”
Who is affected: standalone LXD, MicroCloud clusters, and snap installs
- The CVE record lists LXD versions 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected — specifically the releases before the fixed release that follows each listed version.
- A standalone LXD server does not expose the network API by default; it listens only on a local socket unless an administrator enables the network API with the core.https_address setting. Exploitability therefore requires network access to the HTTPS API.
- MicroCloud clusters present a different exposure: Canonical said an attacker who can capture a member’s public certificate as it joins the cluster can then log in as that member.
- Ubuntu archive packages of LXD are listed as not affected or not shipped; Canonical’s fixed releases are delivered as snaps.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogCanonical, Incus, and the public vulnerability record
The issue was reported by the Incus project, a community fork of LXD; Incus fixed the same flaw in version 7.6.0. Canonical confirmed the flaw affected LXD and released fixed snap versions for LXD and MicroCloud.
The CVE record carries a U.S. CISA assessment, dated October 30, that the flaw is not known to have been exploited. The vulnerability is not on CISA’s Known Exploited Vulnerabilities list, and there is no public sign a working exploit has been published.
What this means for MicroCloud clusters, LXD snap users, and Incus users
- MicroCloud cluster operators should be aware that an attacker who can observe a member joining the cluster and capture that member’s public certificate can later authenticate as that member. Restricting who can observe or access cluster join traffic is therefore a practical concern until patched.
- LXD users who installed via snap must update to the fixed snap releases. Canonical’s advisory instructs snap users to run: sudo snap refresh lxd and sudo snap refresh microcloud, and to verify the version after the refresh because the fixed point releases were still rolling from the candidate channel to stable at the time of the advisory.
- Incus users should move to Incus 7.6.0, which fixed this impersonation flaw along with 17 other security issues; Incus advised there is no configuration mitigation beyond restricting network access to the listener.
Mitigation steps, limitations, and the immediate outlook
Canonical provided no temporary workaround for LXD in its advisory. Because exploitation requires network access to the HTTPS API and the public certificate of a trusted client, administrators can reduce risk by limiting which hosts may reach the API listener until they have applied fixes.
Incus explicitly stated there is no configuration fix and recommended restricting network access to the listener as the only interim control. Administrators should also verify whether their deployment uses LXD snaps (the fixed releases) rather than archive packages, since the advisory notes Ubuntu archive packages are listed as not affected or not shipped.
The practical risk hinges on two concrete prerequisites: network reachability of the HTTPS API and access to a trusted client’s public certificate. Both are fixable and observable conditions — which makes timely patching, network filtering, and verification of post-refresh versions the clear immediate priorities.
