Critical LXD and MicroCloud Flaw Allows Attackers to Impersonate Trusted Clients

A recently revealed defect affecting Canonical's LXD container manager and the MicroCloud orchestration utility has been assigned a flawless CVSS rating of 10.0, denoting maximum severity. This weakness permits an adversary with access to the services' HTTPS API to log in as any authorized client without needing the client’s private key, as long as the public certificate is available.

The root cause lies in a logical mistake in how LXD and MicroCloud confirm client identities during TLS negotiations. By tampering with the authentication sequence, an attacker can submit a counterfeit request that the server treats as originating from a genuine client, thereby sidestepping the cryptographic safeguards that ordinarily demand the private key.

To exploit the flaw, two prerequisites must be satisfied: reachable network connectivity to the compromised API endpoint and the target client’s public certificate, which can frequently be harvested from earlier exchanges or public repositories. With these in hand, the attacker can carry out privileged actions such as spawning containers, altering configurations, and possibly gaining complete control over the host that runs LXD or MicroCloud.

Canonical has confirmed the vulnerability and issued fixes for the impacted LXD and MicroCloud releases. It recommends that administrators promptly install the patches, limit API accessibility to trusted networks, and adopt extra network‑level defenses like firewalls and mutual TLS when possible. Additionally, users should rotate their certificates post‑patch to purge any lingering compromised trust links.

This finding underscores the wider danger of exposing management APIs to the internet without strong access controls. Researchers point out that even sound cryptographic designs can be defeated by implementation errors, reinforcing the importance of thorough code reviews and ongoing vulnerability scanning in cloud‑native settings.