Canonical has released fixes for a certificate-checking flaw that lets attackers impersonate trusted LXD and MicroCloud clients without their private keys, The Hacker News reports. Ubuntu’s October 30 security notice identifies the LXD vulnerability as CVE-2026-112816, which can give an unauthenticated attacker full access to a cluster and its managed virtual machines.
Exploitation requires network access to the HTTPS API—the encrypted interface used to manage the service—and the public certificate of an identity the server trusts. The attacker gains that identity’s access; impersonating a privileged account could also provide root access to the host machine, Canonical said in statements reported by The Hacker News.
Standalone LXD installations do not expose this network interface by default. They listen on a local socket unless an administrator enables network access through core.https_address. MicroCloud, which combines machines running LXD into a cluster, has a particular exposure: Canonical said an attacker who captures a member’s public certificate while it joins the cluster can subsequently impersonate that member.
The vulnerability carries a maximum Common Vulnerability Scoring System severity score of 10.0, while Ubuntu assigns it a separate remediation priority of Medium. The Hacker News reports that an October 30 CISA assessment in the CVE record described exploitation as not known; the flaw was absent from CISA’s Known Exploited Vulnerabilities catalog, and no working exploit had been published.
How a public certificate becomes a login
LXD and MicroCloud support mutual TLS, a connection setup in which clients present certificates to establish their identity. Servers keep accepted identities in a trust store. A public certificate is not secret; its matching private key is supposed to prove that the client owns the identity.
The flaw breaks that distinction. During connection setup, TLS proves possession of the private key for only the first certificate presented, called the leaf certificate. The vulnerable authentication checks nevertheless compared every certificate in the client’s chain against the trust store, including additional certificates the client could freely attach.
An attacker could therefore present their own certificate first and append a trusted client’s public certificate. The server would accept the trusted identity even though the attacker did not possess its private key.
The Incus project, a community fork of LXD, reported the issue, and Canonical confirmed that LXD was also affected, The Hacker News said. Incus published its own security advisory on October 29, a day before Ubuntu’s notice. Its advisory says the behavior has existed since Incus’s initial release and affects versions earlier than 7.6.0.
Incus describes additional paths to access
The Incus advisory details consequences within that product beyond impersonating an ordinary client. Anyone able to reach its HTTPS listener can impersonate a trusted client, metrics identity or server certificate whose public certificate they possess. Impersonating a cluster member bypasses authorization entirely.
Obtaining a suitable public certificate may require no prior access in Incus: servers return their certificates during every TLS handshake. Appending the target server’s own certificate grants access to the database gateway; appending another cluster member’s certificate grants internal cluster access. Trusted clients can also retrieve client certificates through the certificates API, and certificates can be obtained from servers those clients have contacted.
Incus says the flaw also permits renewal or deletion of any trust-store entry through self-service paths and affects authentication of the agent connection between hosts and virtual machines.
A further consequence involves the authorization scriptlet, a script used to make access decisions. Incus passed the unverified certificate chain to that script, allowing attacker-chosen certificates to influence its decisions. This also affects clients authenticating through tokens or OpenID Connect, an identity-based sign-in method, because they can still present arbitrary certificates during TLS setup.
Those detailed impacts are findings from the Incus advisory. It tracks the issue as GHSA-xg75-xf37-cph9 and lists no known CVE identifier.
Fixed releases and steps for administrators
Ubuntu’s notice lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected before their respective fixed releases. The Hacker News reports these fixed snap releases, grouped by product and channel:
- LXD
6/stable: 6.10.1. - LXD
5.21/stable: 5.21.9. - LXD
5.0/stable: 5.0.11. - LXD
4.0/stable: 4.0.15. - MicroCloud
3/stable: 3.4.1. - MicroCloud
2/stable: 2.1.5.
Ubuntu’s archive-package status is separate from these snap installations. Its LXD packages for Ubuntu 20.04, 18.04 and 16.04 are marked not affected; LXD is listed as not in the 22.04, 24.04, 26.04 and 26.10 releases.
Administrators using snaps should update the installed products with sudo snap refresh lxd and sudo snap refresh microcloud. Canonical said the fixed LXD point releases were still moving from the candidate channel to stable when its advisory appeared, so administrators should verify the installed version after refreshing.
The Hacker News reports that Canonical’s advisory offers no temporary LXD workaround. Restricting network access to the HTTPS API reduces exposure while updates are applied. Incus explicitly recommends limiting its HTTPS listener to trusted hosts and says there is no configuration-based workaround. Incus administrators should upgrade to 7.6.0, which fixes this flaw alongside 17 other security issues.
