Skip to content
Centoculus

Security alert · Critical

Critical LXD and MicroCloud flaw lets attackers impersonate trusted clients

· 3 minutes read · Centoculus Security Team

Known since

Affected: Canonical LXD and MicroCloud (affected versions: see vendor advisory)

What happened

On 1 November 2026 a critical flaw in Canonical LXD and MicroCloud was made public. It is rated CVSS 10.0. The flaw lets an attacker authenticate to the LXD HTTPS API as a trusted client without having that client's private key.

To exploit it, the attacker needs two things: network access to the HTTPS API and the public certificate of a trusted client. A public certificate is not secret by design, so this should not be treated as a strong barrier. With a successful attack, the attacker gains access to the cluster and the virtual machines running on it.

There are no reports of active exploitation at this time.

Who is affected

Operators of LXD hosts and MicroCloud clusters whose HTTPS API is reachable over the network. This includes setups where remote clients, other cluster members or management tools connect to LXD using client certificates. Systems where the API listens only on the local Unix socket and is not exposed over HTTPS are at much lower risk.

The source data does not list the affected or fixed versions. Check the vendor advisory linked below for the exact versions.

What to do now

  1. Find all hosts running LXD or MicroCloud, including cluster members and test or lab systems.
  2. Check the advisory linked below for the fixed versions and update every host. On snap installations this is typically done with snap refresh lxd and snap refresh microcloud; confirm the installed version afterwards with snap list lxd microcloud.
  3. Restrict network access to the LXD HTTPS API (by default TCP port 8443) with a firewall, so that only trusted management hosts and cluster members can reach it. Do not expose the API to the internet.
  4. If you do not use remote access, consider disabling the HTTPS listener by unsetting core.https_address, so LXD is only reachable through the local Unix socket.
  5. After updating, verify that instances and cluster members are healthy, for example with lxc cluster list and lxc list.

How to check whether you are affected

  • Check whether the API listens on the network: lxc config get core.https_address or ss -tlnp | grep 8443.
  • Compare the installed version (snap list lxd microcloud) with the fixed versions in the vendor advisory.
  • Review the trusted clients with lxc config trust list and remove entries you do not recognise.
  • Look through the LXD logs and the operations history (lxc operation list, journalctl -u snap.lxd.daemon) for unexpected API calls, new instances, configuration changes or console and exec sessions, especially from unfamiliar IP addresses.
  • If you find signs of unauthorised access, treat the affected instances as compromised: isolate them, rotate credentials and certificates, and restore from known good backups.

Sources

Related posts