Critical LXD and MicroCloud Flaw Allows Attackers to Impersonate Trusted Clients

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

The problem originates from a logical mistake in how LXD and MicroCloud verify client identities during TLS handshakes. 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 cryptographic safeguards that ordinarily demand the private key.

To exploit the flaw, two prerequisites must be satisfied: network reachability to the vulnerable API endpoint and access to the target client’s public certificate, which can frequently be harvested from earlier exchanges or public repositories. With these in hand, the attacker can perform privileged actions such as creating containers, altering configurations, and possibly achieving complete system takeover on the host operating LXD or MicroCloud.

Canonical has confirmed the issue and issued patches for the impacted LXD and MicroCloud releases. It recommends that administrators promptly install the fixes, limit API accessibility to trusted networks, and add extra network‑level safeguards like firewalls and mutual TLS where possible. Additionally, users should rotate their certificates after updating to remove any lingering compromised trust links.

This finding underscores the wider danger of exposing management APIs to the internet without strong access controls. Security researchers note that even well‑engineered cryptographic mechanisms can be subverted by implementation errors, highlighting the importance of thorough code reviews and ongoing vulnerability scanning in cloud‑native settings.