Critical CVSS 10.0 flaw lets attackers impersonate trusted LXD and MicroCloud clients

A certificate-chain weakness in Canonical's LXD and MicroCloud lets an attacker log in as a trusted client using only its public certificate, with no private key.

Critical CVSS 10.0 flaw lets attackers impersonate trusted LXD and MicroCloud clients

At a glance

  • CVE-2026-112816 carries a maximum CVSS score of 10.0 and affects Canonical's LXD and MicroCloud.
  • An attacker needs network access to the HTTPS API and a trusted client's public certificate, which is not secret, according to The Hacker News.
  • Canonical says impersonating a privileged account could give an attacker root access to the host machine.
  • Fixes are in LXD snaps 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 3.4.1 and 2.1.5; the community fork Incus fixed it in 7.6.0.

Canonical has disclosed a maximum-severity flaw in its LXD container and virtual-machine manager and in MicroCloud that lets an attacker log in as a trusted client without possessing that client's private key. The Hacker News reported on November 1, 2026 that the vulnerability, tracked as CVE-2026-112816, carries a CVSS score of 10.0. There is no public sign of exploitation, but the flaw can expose an entire cluster and, in the worst case, the host machine.

What happened

According to The Hacker News, the Incus project, a community fork of LXD, reported the flaw, and Canonical confirmed that LXD is also affected. The report says an attacker "had to reach their HTTPS API over the network and have the trusted client's public certificate" to carry out the attack. Because a public certificate is not secret, that requirement is far weaker than it sounds. Canonical said that if the impersonated account is privileged, the attacker could gain "root access to the host machine."

Technical details

The Hacker News explains that LXD and MicroCloud rely on mutual TLS, treating a client as trusted when its certificate is in the server's trust store. The server checked every certificate the client presented against that store. The problem, the report says, is that a TLS connection only proves possession of the leaf certificate's private key; the rest of the chain is whatever the client chooses to attach. An attacker can therefore attach a trusted client's public certificate behind their own certificate, and the server accepts the connection as that trusted client. For MicroCloud, Canonical warns of a specific weak point: an attacker who captures a member's public certificate as it joins the cluster can then log in as that member.

Who is affected

Per the CVE record cited by The Hacker News, affected LXD versions include 4.0.14, 5.0.10, 5.21.8 and 6.9, each before its fixed release. The report notes that a standalone LXD server does not expose its API by default; it listens only on a local socket unless the network API is enabled via core.https_address. A CISA assessment dated October 30, cited in the CVE record, says the flaw is not known to have been exploited, and it is not on CISA's Known Exploited Vulnerabilities list.

What to do

The Hacker News says the fix is to update to patched builds. On snap installs, administrators should run sudo snap refresh lxd and sudo snap refresh microcloud. The fixed releases are LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 3.4.1 and 2.1.5. The report notes Canonical said the fixed LXD point releases were still moving from the candidate channel to stable when its advisory went out, so administrators should verify the installed version after refreshing. The community fork Incus addressed the same issue in version 7.6.0, which the report says also fixes 17 other security issues. Canonical offers no temporary workaround for LXD, but because the attack requires network access to the API, restricting who can reach it reduces risk until patching is complete.

Related CVEs

Sources

This story is based on the sources listed above. Always check the vendor’s official advisory before acting on critical systems.