Max-Severity LXD, MicroCloud Bug Enables Client Impersonation

Maximum-Severity Flaw Let Attackers Pose as Trusted LXD and MicroCloud Clients

A vulnerability in Canonical's LXD and MicroCloud received the maximum possible severity score of 10.0 on the Common Vulnerability Scoring System (CVSS), the industry-standard 0 to 10 scale used to rate how easily a flaw can be exploited and how much damage it can cause. LXD is Canonical's system for managing Linux containers and virtual machines, commonly used by hosting providers, managed service providers (MSPs), and internal IT teams to run multi-tenant infrastructure. MicroCloud is Canonical's clustering layer built on top of LXD, designed to let organizations stand up small, self-managed private clouds across multiple servers.

According to the report, the flaw let an attacker log in as a trusted client of an LXD or MicroCloud cluster without ever holding that client's private key, the secret half of a cryptographic key pair normally required to prove identity in certificate-based authentication. To exploit it, an attacker needed two things: network reach to the cluster's HTTPS API, the web-based interface administrators and automation tools use to manage the cluster, and a copy of the trusted client's public certificate, which is not secret and is often shared or stored in configuration files, automation pipelines, or version control.

Once authenticated, the attacker would operate with the same access as the client being impersonated, reaching the cluster and the virtual machines running on it. If the impersonated identity carried administrative privileges, the practical result could be broad control over the cluster's workloads and data.

Who This Affects: Self-Hosted Cloud and Container Operators

This flaw matters most to organizations that run their own LXD or MicroCloud infrastructure rather than relying on a public cloud provider, a group that includes MSPs hosting client workloads, universities and labs running shared compute clusters, and small-to-midsize businesses that chose self-managed virtualization to control costs or data residency. Canonical markets MicroCloud specifically at organizations that want cloud-style flexibility without handing infrastructure to a third party, which means the teams most exposed to this bug are often the same ones with the leanest security operations staff.

The mechanics of the flaw are notable because they undercut an assumption many administrators rely on: that certificate-based authentication is safe as long as private keys stay secret. Here, the public certificate alone, something that is routinely logged, backed up, or passed between systems without the same handling rigor as a private key, was reportedly enough to authenticate as a trusted party. That distinction matters for incident response too: if your organization ran LXD or MicroCloud with internet-reachable management APIs before a fix was available, a forensic review should not stop at checking whether private keys were exposed.

What Operators Should Do Now

Bellator Cyber Guard recommends the following steps for any practice, MSP, or business running LXD or MicroCloud:

• Check your version and apply Canonical's fix. Consult Canonical's official security advisories for the patched release and validate it in a test environment before rolling it out broadly.
• Take the HTTPS management API off the open internet. Restrict access to a VPN, bastion host, or management VLAN; this API should not need to be reachable from an arbitrary public IP address.
• Audit who holds trusted client certificates. Inventory every certificate trusted by your cluster and confirm each one maps to a known, currently-authorized user or automation account.
• Rotate certificates after patching. Because public certificates were reportedly sufficient for impersonation, treat any certificate that may have been exposed, logged, or stored insecurely as suspect and reissue it.
• Review access logs for anomalies. Look for API authentications from unexpected IP addresses or unusual hours tied to accounts with administrative scope on virtual machines.

For healthcare practices and tax professionals using self-hosted virtualization to keep patient or financial data off public cloud platforms, this flaw is a reminder that self-hosting shifts responsibility, not risk, away from you. A cluster holding electronic health records or tax filings that was reachable over the open internet before a patch was applied should be reviewed under your organization's incident response and breach assessment procedures, even if no confirmed compromise has been found.