I’M UNDER A CYBER ATTACK

Alert

Alert 2026-135 Critical flaw in Canonical LXD and MicroCloud allows impersonation of trusted clients

Affected product(s): 

Product (snap track)Affected versionsFixed version
Canonical LXD, track 6 / latestBefore 6.10.16.10.1
Canonical LXD, track 5.21 (LTS)5.21.8 and earlier5.21.9
Canonical LXD, track 5.0 (LTS)5.0.10 and earlier5.0.11
Canonical LXD, track 4.0 (LTS)4.0.14 and earlier4.0.15
Canonical MicroCloud, track 3Before 3.4.13.4.1
Canonical MicroCloud, track 2Before 2.1.52.1.5

Only servers with the LXD HTTPS API enabled on the network are exposed, as is always the case in LXD clusters and in all MicroCloud installations.

Description

A critical-severity vulnerability (CVSSv4 10.0 – CRITICAL) has been disclosed in Canonical LXD, Ubuntu’s container and virtual machine manager, and MicroCloud, the LXD-based private cloud solution. It allows an attacker without credentials who can reach the HTTPS API to authenticate as any trusted client. The vulnerability has been assigned CVE-2026-112816 and is an incorrect certificate validation issue (CWE-295).

The flaw lies in the mutual TLS (mTLS) authentication of the remote API. The TLS handshake only proves that the client holds the private key of the first certificate in the chain, but LXD compared all certificates in the submitted chain against its trust list. An attacker who adds the public certificate of a trusted client as an intermediate certificate can impersonate that client without having its private key. Public certificates are not secrets: they are exchanged in TLS connections and can be obtained from any client machine.

According to the vendor, depending on the privileges of the impersonated identity, the attacker may gain root access on the host, and the vulnerability record also indicates full access to the cluster and managed virtual machines. In MicroCloud, the attacker can intercept the public certificate of a member joining the cluster and then authenticate as that member.

The vendor stated that the flaw was reported to them by researchers from an LXD-derived project that was also affected. According to those researchers, the issue has existed since the initial version of the code and there is no way to mitigate it through configuration.

Exposure requires the HTTPS API to listen on the network (core.https_address or cluster.https_address configured). By default, LXD only listens on a local Unix socket, but the API is always exposed in LXD clusters, in MicroCloud, and on hosts managed remotely or through the web interface. The lxd packages in supported Ubuntu releases are listed as unaffected or do not exist, since LXD has been distributed as a snap since Ubuntu 20.04.

The vendor released the fixed versions on 29/10/2026 through a staged rollout from the candidate channel to the stable channel. The stable channels for LXD tracks 5.21, 5.0, and 4.0 only began serving the fixed versions on 01/11/2026 at 02:10 (PYT), so a snap refresh performed before that time may not have installed the fix.

No active exploitation has been reported, the vulnerability does not appear in the U.S. cybersecurity agency’s Known Exploited Vulnerabilities (KEV) catalog, and no public exploit code has been identified. A government source assesses that exploitation can be automated and that the technical impact is total.

Mitigation

The vendor has not published a temporary mitigation. While the update is being applied, it is recommended to:

  • Restrict access to the LXD HTTPS API port (8443/tcp by default) to trusted management hosts, using a firewall or access control lists, and do not expose it to the Internet.
  • If remote access is unnecessary and the server is not part of a cluster, disable the networked API with lxc config unset core.https_address.
  • In MicroCloud, do not add new members to the cluster over untrusted networks until it has been updated.

Detection and verification of exposure

The vendor has not published indicators of compromise. General recommendations:

  • Check the installed version, revision, and track using snap list lxd microcloud and snap info lxd | grep -E 'tracking|installed'.
  • Check whether the HTTPS API is listening on the network using lxc config get core.https_address and lxc config get cluster.https_address (an empty value indicates that the API is only listening locally) and ss -tlnp | grep 8443.
  • In clusters, confirm with lxc cluster list that all members are running the fixed version.
  • Review the trusted identities with lxc config trust list and remove any that are not recognized.
  • Review recent service activity (journalctl -u snap.lxd.daemon, lxc operation list, lxc list --all-projects) for any unexplained instances, configuration changes, or command executions.

Solution

The solution is to update LXD and MicroCloud to the fixed version for their respective track:

  • sudo snap refresh lxd (LXD 6.10.1, 5.21.9, 5.0.11, or 4.0.15, depending on the track).
  • sudo snap refresh microcloud (MicroCloud 3.4.1 or 2.1.5, depending on the track).

Because the LXD 5.21, 5.0, and 4.0 tracks received the fix in the stable channel only on 01/11/2026 at 02:10 (PYT), it is recommended to verify with snap list lxd that the installed version is the fixed version (5.21.9, 5.0.11, or 4.0.15) and, if it is not, rerun sudo snap refresh lxd.

In clusters, all members must be updated because LXD requires the same version throughout the cluster. The LXD 3.0 and MicroCloud 1 tracks have no fix and must be migrated to a supported track. After updating, it is recommended to review the list of trusted identities and, if unauthorized access is suspected, renew the client certificates and review instances, profiles, and devices.

For information on how to update, visit the following link:

https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557

Additional information: