A critical security flaw in Canonical's LXD and MicroCloud products allowed attackers to log in as trusted clients without possessing the client's private key, according to a report published by The Hacker News. To exploit the vulnerability, an attacker needed network access to the HTTPS API and the trusted client's public certificate. Once authenticated, the attacker could operate as that client, gaining access to the cluster and its virtual machines — and if the impersonated account held elevated privileges, the attacker could obtain "root access to the host machine," Canonical stated. The flaw, tracked as CVE-2026-112816, received a maximum CVSS score of 10.0, and Canonical has released patched versions of both products.
The vulnerability targeted how LXD and MicroCloud verify remote clients through mutual TLS, a system where clients present certificates to prove their identity. The server checked every certificate the client sent against its trust store — the list of accepted identities — but a TLS connection only proves the client holds the private key for the first certificate in the chain, known as the leaf. An attacker could attach a trusted client's public certificate, which isn't secret, behind their own in the chain, and the server would accept them as that client. The CVE record lists LXD versions 4.0.14, 5.0.10, 5.21.8, and 6.9 as affected, each before the corresponding fixed release. Canonical released fixes across multiple snap channels: LXD 6.10.1 in the 6/stable channel, 5.21.9 in 5.21/stable, 5.0.11 in 5.0/stable, 4.0.15 in 4.0/stable, MicroCloud 3.4.1 in 3/stable, and 2.1.5 in 2/stable. Ubuntu's archive packages of LXD are listed as either not affected or not shipped, so the fixed releases are the snaps.
The flaw originated outside Canonical. The Incus project, which started as a community fork of LXD, reported the vulnerability, and Canonical confirmed it affected LXD as well, the report notes. Incus patched the same issue in version 7.6.0. There's no public evidence the flaw has been used in an attack — the CVE record includes a U.S. CISA assessment from October 30 stating the vulnerability isn't known to have been exploited, it doesn't appear on CISA's Known Exploited Vulnerabilities list, and no working exploit has been published. Exploiting the flaw requires two components: network access to the HTTPS API and the public certificate of a client the server already trusts. A standalone LXD server doesn't expose that API by default — it listens only on a local socket unless an administrator enables the network API with the core.https_address setting. MicroCloud, which links multiple machines running LXD into a single cluster, presents a specific vulnerability point where an attacker who can capture a member's public certificate as it joins the cluster can then authenticate as that member.
Canonical recommended updating LXD and MicroCloud to the fixed versions by running sudo snap refresh lxd and sudo snap refresh microcloud on snap installations. The company noted the fixed LXD point releases were still rolling out from the candidate channel to stable at the time of its advisory, urging users to verify the version after refreshing rather than assuming the fix arrived. Canonical's advisory provided no temporary workaround for LXD, though limiting network access to the API reduces risk until updates are applied. The Incus project, reporting the same flaw, said there's no configuration fix and that the only step is restricting network access to the listener, with Incus users urged to move to version 7.6.0, which patched this flaw alongside 17 other security issues. Organizations running these tools should prioritize the update immediately given the maximum severity score and the potential for full host compromise. The absence of known exploitation provides a window to patch before threat actors develop working exploits, but that window won't stay open indefinitely.