Canonical LXD and MicroCloud (versions before their respective fixed releases)

LXD uses mutual TLS (Transport Layer Security — a protocol that verifies identity by requiring both sides to present certificates) to authenticate remote clients. The server checked every certificate a client presented against its list of trusted identities, but a TLS connection only proves ownership of the first — the "leaf" — certificate in the chain. The attacker could attach a trusted client's public certificate, which is not a secret, further back in the chain. The server saw the trusted cert and waved them through. It is like a bouncer checking the back of your ID queue rather than the person holding it.

An attacker needs two things: network access to the HTTPS API, and the public certificate of any client the server already trusts. In a MicroCloud cluster, that certificate is briefly visible as members join. With both in hand, the attacker builds a TLS chain with the trusted cert at the back, connects to the API, and is accepted as that trusted client — with full access to the cluster, its virtual machines, and, if the impersonated account is privileged, root access to the physical host.

1. Check API access logs for connections from unexpected IP addresses presenting certificates belonging to known cluster members.
2. Look for administrative API calls — such as VM creation, deletion, or configuration changes — that do not correspond to scheduled operations.
3. Monitor for new container or VM instances you did not create.

1. Run sudo snap refresh lxd and sudo snap refresh microcloud immediately. Verify the installed version after refresh.
2. Until patched, restrict network access to the LXD HTTPS API using firewall rules — only allow known, trusted IP addresses.
3. Incus users (the community fork of LXD) should upgrade to version 7.6.0.