CVSS 10.0: How a Single Public Certificate Unlocks Root Access in LXD and MicroCloud
Executive Summary
A maximum-severity vulnerability (CVE-2026-112816, CVSS 10.0) in Canonical's LXD container hypervisor and MicroCloud clustering platform allows a network-adjacent attacker to impersonate any trusted client without possessing that client's private key. By exploiting a flaw in mutual-TLS certificate-chain validation, an attacker who obtains a trusted client's public certificate—information that is not secret—can attach it to their own TLS handshake and be accepted as that client. If the impersonated identity carries administrative rights, the attacker gains root access to the underlying host. Canonical released fixed snap versions (LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15; MicroCloud 3.4.1, 2.1.5) following disclosure by the Incus community fork, which patched the same flaw in version 7.6.0.
This incident underscores a growing pattern of authentication-bypass flaws in cloud-native infrastructure control planes. As organizations scale containerized and clustered workloads, improperly validated identity in east-west API paths creates a silent privilege-escalation highway—an attack surface that perimeter firewalls and endpoint agents alone cannot address.
Why This Matters Now
Container orchestration platforms like LXD and MicroCloud are increasingly the backbone of private-cloud and edge deployments. A CVSS 10.0 authentication bypass that requires only a public certificate—obtainable during routine cluster join operations—means any attacker with internal network visibility can silently acquire root on physical hosts. With no known workaround beyond patching or network restriction, and with cluster join traffic observable by any insider or compromised workload, this flaw is urgent for every enterprise running LXD-based infrastructure today.
Attack Path Analysis
An attacker with network access to the LXD/MicroCloud HTTPS API and possession of a trusted client's public certificate exploited CVE-2026-112816 to bypass mutual TLS authentication by appending the trusted certificate behind their own in the TLS chain, causing the server to authenticate them as the trusted client without requiring the private key. Once authenticated as a trusted — potentially privileged — cluster member, the attacker could escalate to root on the host, pivot laterally across cluster nodes, establish persistent command and control, exfiltrate data from virtual machines, and ultimately destroy or ransomware workloads across the MicroCloud cluster.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
The attacker obtained a trusted client's public certificate — exposed during MicroCloud cluster join operations or retrieved from public sources — and used it to craft a malicious TLS certificate chain. By appending the trusted certificate behind their own leaf certificate, they exploited the flawed certificate chain validation in CVE-2026-112816 to authenticate to the LXD/MicroCloud HTTPS API without possessing the corresponding private key. This required only network access to the API endpoint (core.https_address enabled) and the non-secret public certificate.
Related CVEs
CVE-2026-112816
CVSS 10A critical authentication bypass vulnerability in Canonical LXD and MicroCloud allows a remote attacker with network access to the HTTPS API and possession of a trusted client's public certificate to impersonate that client without holding its private key, potentially gaining root access to the host machine if the impersonated account is privileged.
Affected Products:
Canonical LXD – < 4.0.15, < 5.0.11, < 5.21.9, < 6.10.1
Canonical MicroCloud – < 2.1.5, < 3.4.1
Linux Containers Incus – < 7.6.0
Exploit Status:
no public exploitReferences:
MITRE ATT&CK® Techniques
Unsecured Credentials: Private Keys
Use Alternate Authentication Material: Application Access Token
Valid Accounts
Exploit Public-Facing Application
Abuse Elevation Control Mechanism
Network Boundary Bridging
Remote Service Session Hijacking
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
PCI DSS 4.0 – Strong Authentication for System Components
Control ID: Requirement 8.6.1
NYDFS 23 NYCRR 500 – Multi-Factor Authentication and Cryptographic Controls
Control ID: Section 500.12
DORA (Digital Operational Resilience Act) – ICT Access Control and Authentication Integrity
Control ID: Article 9 – ICT Security Policies and Access Controls
NIS2 Directive – Authentication and Access Security Policies
Control ID: Article 21(2)(a) – Policies on Risk Analysis and Information System Security
CISA Zero Trust Maturity Model 2.0 – Continuous Cryptographic Identity Verification
Control ID: Identity Pillar – Identity Verification and Validation
ISO/IEC 27001:2022 – Control of Privileged Access and Authentication Mechanisms
Control ID: Annex A 8.2 – Privileged Access Rights
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
Critical CVSS 10.0 authentication bypass in LXD/MicroCloud exposes IT infrastructure clusters to privilege escalation, enabling root host access via forged mTLS certificate chains without private key possession.
Computer/Network Security
Zero Trust segmentation and east-west traffic controls are critically undermined when attackers impersonate trusted cluster members, bypassing identity-based policy enforcement across virtualized multi-node environments.
Cloud Computing
MicroCloud cluster deployments face lateral movement risk as certificate interception during node onboarding grants attacker-controlled privileged access, violating NIST.800-53.AC-6 and ZTMM.Network compliance mandates.
Government Administration
Public sector LXD deployments with network-exposed HTTPS APIs face elevated privilege escalation risk, threatening NIST.800-53.SC-7 compliance and critical infrastructure integrity through unauthorized cluster impersonation.
Sources
- CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Keyhttps://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.htmlVerified
- Security Advisory: Critical Vulnerability Found in Canonical LXD and MicroCloudhttps://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557Verified
- Ubuntu Security CVE-2026-112816https://ubuntu.com/security/CVE-2026-112816Verified
- Incus Security Advisory GHSA-xg75-xf37-cph9: TLS Certificate Chain Authentication Bypasshttps://github.com/lxc/incus/security/advisories/GHSA-xg75-xf37-cph9Verified
- Incus 7.6.0 Release Noteshttps://discuss.linuxcontainers.org/t/incus-7-6-has-been-released/27462Verified
- CISA Known Exploited Vulnerabilities Cataloghttps://www.cisa.gov/known-exploited-vulnerabilities-catalogVerified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is relevant here because the attacker exploited a forged certificate chain to authenticate to an exposed LXD API and then moved freely across a MicroCloud cluster — exactly the kind of unrestricted east-west and API reachability that Zero Trust segmentation is designed to constrain. By enforcing identity-aware network boundaries and controlling which workloads can reach cluster management APIs, CNSF would likely reduce the attacker's blast radius even when authentication controls have been bypassed.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: Network-layer segmentation would likely constrain which source workloads and IP ranges could even reach the LXD HTTPS API endpoint, reducing the pool of attacker positions from which this certificate chain exploit could be attempted in the first place.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation policies would likely constrain the network paths through which an authenticated-but-impersonated identity could exercise API-driven control across host boundaries, reducing the lateral scope of any privilege abuse that follows.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement would likely constrain the attacker's ability to pivot freely between cluster nodes and virtual machines, limiting inter-workload reachability to only those paths explicitly permitted by policy rather than implicitly granted by cluster membership.
Control: Multicloud Visibility & Control
Mitigation: Centralized multicloud traffic visibility would likely surface anomalous API call patterns and unexpected outbound connection attempts from cluster nodes, giving operators earlier signals of attacker-controlled activity and reducing the window during which command and control channels could operate undetected.
Control: Egress Security & Policy Enforcement
Mitigation: Egress policy enforcement would likely constrain outbound data transfer paths from compromised workloads, reducing the attacker's ability to bulk-exfiltrate sensitive VM data to arbitrary external destinations over unmonitored encrypted channels.
If earlier CNSF segmentation and egress controls constrained lateral movement and outbound paths, the attacker's destructive reach would likely be limited to fewer cluster nodes and a reduced set of workloads rather than spanning the full MicroCloud environment — shrinking the scope of ransomware deployment or data destruction to a more contained blast radius.
Impact at a Glance
Affected Business Functions
- Cloud Infrastructure Orchestration and Cluster Management
- Virtual Machine and Container Workload Hosting
- Privileged System Administration and Root Access Controls
- Multi-Tenant Workload Isolation and Tenant Data Separation
Estimated downtime: 1 days
Estimated loss: N/A
An attacker successfully exploiting this vulnerability could gain root-level access to host machines within an LXD or MicroCloud cluster. This exposes all data processed or stored on affected nodes, including container and virtual machine workloads, inter-cluster communication secrets, API credentials, configuration data, and any tenant or organizational data hosted within the cluster. In MicroCloud deployments, a cluster member certificate captured during the join handshake is sufficient to impersonate that member, placing all clustered nodes and their data at risk. No confirmed data breach has been reported at this time, but the theoretical exposure is severe given the CVSS 10.0 severity and the potential for unauthenticated root access across networked nodes.
Recommended Actions
Key Takeaways & Next Steps
- • Apply Zero Trust Segmentation (CNSF) to enforce identity-based policy at the network layer so that even authenticated API sessions from unexpected source identities or IP ranges are denied, ensuring a bypassed mTLS check alone is insufficient to reach cluster resources without additional verified identity context.
- • Deploy East-West Traffic Security controls to inspect and restrict workload-to-workload and node-to-node API communication within MicroCloud clusters, limiting an impersonated cluster member's ability to pivot laterally across nodes and virtual machines after initial authentication bypass.
- • Enable Multicloud Visibility & Control with centralized traffic observability to baseline normal LXD API interaction patterns and alert on anomalous certificate presentations, repeated malformed authentication requests, or unexpected cluster join sequences indicative of CVE-2026-112816 exploitation attempts.
- • Enforce Egress Security & Policy Enforcement with FQDN filtering and outbound traffic controls on all LXD host and VM egress paths to detect and block unauthorized data exfiltration attempts to external destinations following a successful cluster compromise.
- • Immediately patch all LXD and MicroCloud deployments to fixed snap versions (LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15; MicroCloud 3.4.1, 2.1.5) and restrict network access to the HTTPS API endpoint (core.https_address) to trusted network segments only until patching is confirmed, reducing the attack surface for unauthenticated network reachability required by this CVE.
