A Perfect-Score Vulnerability in Widely Used Cloud Infrastructure Tooling

Canonical's LXD and MicroCloud — two projects that underpin a significant amount of private-cloud and container infrastructure — are affected by a maximum-severity authentication flaw that lets an attacker impersonate a trusted client without ever possessing that client's private key. The vulnerability carries a CVSS score of 10.0, the highest possible rating, reflecting both the ease of exploitation under the right conditions and the depth of access an intruder can obtain.

According to reporting from The Hacker News, the issue resides in the way the affected systems authenticate clients connecting to their HTTPS API. LXD exposes a REST API over TLS, and clients are traditionally authenticated through certificate-based mutual TLS: the server trusts a client's public certificate, and the client proves possession of the corresponding private key during the handshake. The flaw undermines that second half of the exchange.

How the Attack Works

Exploiting the bug requires two preconditions. First, the attacker must be able to reach the target's HTTPS API over the network. Second, the attacker must already hold the public certificate of a client that the server trusts. When both conditions are met, the attacker can complete authentication as that trusted client — without the matching private key.

That is a meaningful weakening of the trust model. Public certificates are, by design, public: they are exchanged during TLS handshakes, may be embedded in configuration management repositories, and can leak through logs, backups, or misconfigured endpoints. The private key is the secret that is supposed to make impersonation impossible. A flaw that removes the need for it effectively turns a widely shared artifact into a credential.

Once authenticated, the attacker inherits the impersonated client's privileges. In LXD and MicroCloud deployments, trusted clients are typically administrators or automation accounts with broad control over the cluster. That translates into the ability to enumerate and manipulate virtual machines and containers, alter cluster configuration, and potentially pivot further into the environment.

Why the Score Is 10.0

A CVSS score of 10.0 is reserved for vulnerabilities that combine maximum impact with minimal attack complexity. In this case, the attack is network-reachable, requires no user interaction, and grants high confidentiality, integrity, and availability impact because a trusted client can control the workloads and configuration of the cluster. The only mitigating factor is the requirement to obtain a trusted client's public certificate — a barrier, but a low one in many real-world environments where certificates are distributed broadly for legitimate operational reasons.

Who Is Exposed

LXD is used heavily for system container and virtual machine management on Linux, and MicroCloud builds on LXD to provide clustered, highly available private-cloud deployments. Organizations running these tools internally — particularly those that expose their API beyond a tightly restricted management network — should treat this as urgent. The exposure is greatest where the API is reachable from less-trusted network segments, or where client certificates have been shared widely across teams, CI systems, and automation tooling.

Recommended Actions

  • Patch promptly. Apply the vendor's fixed releases for both LXD and MicroCloud as soon as they are available. Given the severity, this should be treated as an emergency change.
  • Restrict API reachability. Limit access to the LXD and MicroCloud HTTPS APIs to trusted management networks, and place them behind network policy or a bastion where feasible.
  • Audit trusted certificates. Review the list of trusted clients configured on each server and cluster, and remove any certificates that are no longer actively needed.
  • Rotate where exposure is suspected. If a trusted client certificate may have been obtainable by an untrusted party, treat the associated trust entry as compromised and re-issue credentials.
  • Hunt for anomalies. Review API access logs for authentication events or administrative actions originating from unexpected source addresses or at unusual times.

The Broader Lesson

Certificate-based authentication is only as strong as its binding between identity and proof of key possession. This flaw is a reminder that mutual TLS implementations deserve the same scrutiny as password-based login flows — and that public certificates should never be treated as secrets. Teams operating private-cloud control planes should assume that any artifact distributed for convenience may eventually end up in the wrong hands, and design their network boundaries accordingly.

Organizations should consult Canonical's advisory for the specific affected versions and fixed releases, and monitor for further technical detail as researchers publish analyses of the underlying authentication path.