As reported by The Hacker News, Canonical has disclosed and patched a critical authentication bypass — CVE-2026-112816 (CVSS 10.0) — affecting LXD and MicroCloud. The vulnerability undermines the mutual TLS (mTLS) trust model that these products rely on for remote API access, allowing an attacker who possesses only a trusted client's public certificate to authenticate as that client without the corresponding private key. This is a significant finding, not just for LXD deployments but for the broader ecosystem of systems that implement mTLS client authentication.
Vulnerability Summary
| Field | Detail |
|---|---|
| CVE | CVE-2026-112816 |
| CVSS | 10.0 (Critical) |
| Vendor | Canonical (LXD, MicroCloud); also affects Incus fork |
| Affected Versions | LXD 4.0.14, 5.0.10, 5.21.8, 6.9; MicroCloud 2.x and 3.x prior to fixed releases; Incus prior to 7.6.0 |
| Patched Versions | LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15; MicroCloud 3.4.1, 2.1.5; Incus 7.6.0 |
| Exploitation in the Wild | None observed publicly; CISA assessed Oct 30, 2026 as not known to be exploited |
| Prerequisites | Network access to HTTPS API + possession of a trusted client's public certificate |
Why This Matters: A Fundamentally Broken Trust Model
The flaw is elegant in its simplicity. In a properly implemented mTLS handshake, the server verifies that the client possesses the private key corresponding to the certificate it presents. The TLS protocol only proves ownership of the leaf certificate — the first in the chain. LXD's server, however, checked every certificate in the client's presented chain against its trust store, treating mere presence in the chain as proof of identity. An attacker could append a trusted client's public certificate — which is not secret and can be obtained through various means — behind their own leaf certificate and be accepted as that trusted identity.
This is a textbook case of conflating knowledge of a credential (the public cert) with possession of a secret (the private key). The TLS protocol already enforces the latter correctly; LXD's application-layer logic overrode that enforcement with a weaker check.
The impact escalates rapidly. If the impersonated client holds privileged access within the LXD cluster, the attacker gains full control over virtual machines and, per Canonical's own advisory, potentially root access to the host machine. In MicroCloud environments, where multiple nodes form a cluster, this could mean compromising an entire orchestration fabric from a single forged authentication.
Who Is at Risk
- MicroCloud cluster operators are the most exposed, as the network API is integral to cluster operations and member certificates are exchanged during node joins — creating a window for certificate capture.
- LXD deployments with
core.https_addressenabled — any administrator who has exposed the remote API over the network is at risk. Standalone LXD with only local socket access is not exposed by default. - Multi-tenant or shared infrastructure using LXD for container/VM isolation faces the highest consequence, as host root compromise breaks all isolation boundaries.
- Incus users on unpatched versions (prior to 7.6.0) carry the same risk.
Immediate Actions
- Patch immediately via snap refresh to the fixed channel versions listed above. For LXD:
snap refresh lxd --channel=6/stable(or your current major version channel). For MicroCloud:snap refresh microcloud --channel=3/stable. - Audit trust stores — review all client certificates in your LXD/MicroCloud trust store and remove any that are stale, unknown, or belong to decommissioned systems.
- Restrict network exposure — if the HTTPS API does not need to be network-accessible, disable
core.https_addressor bind it to localhost. If remote access is required, place it behind a VPN or jump host rather than exposing it directly. - Review certificate handling during cluster joins — for MicroCloud, ensure the join process occurs over a trusted network segment and that certificate exchange cannot be observed by unauthorized parties.
- Rotate client certificates post-patch as a precaution, particularly for any privileged service accounts that connect to the API.
- Check for indicators of compromise — review LXD audit logs for unexpected client connections or API calls from unfamiliar source IPs, especially during the window before patching.
Broader Implications
This vulnerability highlights a recurring pattern in mTLS implementations: the assumption that certificate chain validation at the application layer mirrors the cryptographic guarantees provided by the TLS handshake. It does not. Any system that implements client certificate authentication should verify identity only against the leaf certificate that the TLS layer has cryptographically proven the client controls. Treating intermediate or appended certificates as identity assertions opens the door to exactly this class of impersonation attack.
The fact that this was originally reported by the Incus community fork — and then confirmed to affect upstream LXD — underscores the value of open-source security auditing across forked codebases. Organizations running either LXD or Incus should verify their version lineage and patch accordingly.
Shield53 Recommendations
- Patch all LXD and MicroCloud snap installations to the fixed releases listed above within 48 hours.
- Conduct a full trust store audit and remove unused or untrusted client certificates.
- Network-segment or VPN-protect any LXD HTTPS API endpoints that must remain remotely accessible.
- Implement logging and alerting on LXD API authentication events, with particular attention to certificate fingerprint changes for known clients.
- For environments using Incus, upgrade to version 7.6.0 or later.
- Add this CVE to your vulnerability management tracking with a 7-day remediation SLA given the CVSS 10.0 rating and potential for host compromise.
