CVE-2026-112816: Critical LXD and MicroCloud Authentication Bypass Enables Cluster Takeover

Canonical has released security updates addressing CVE-2026-112816, a critical authentication bypass vulnerability affecting LXD and MicroCloud. The flaw carries a maximum CVSS score of 10.0 and can allow an unauthenticated remote attacker to impersonate a trusted TLS client without possessing that client’s private key.

Successful exploitation can provide access to the LXD or MicroCloud API with the privileges assigned to the impersonated identity. When the trusted identity has sufficient permissions, an attacker may gain full access to the cluster, managed virtual machines, and potentially root-level access to the underlying host.

The vulnerability stems from improper validation of client certificate chains used for mutual TLS authentication. Instead of authenticating only the leaf certificate for which the client proves possession of the corresponding private key, vulnerable implementations compare every certificate supplied in the client-controlled chain against trusted certificates.

An attacker who can reach the HTTPS API and obtain the public certificate of an already trusted client can therefore append that certificate behind an attacker-controlled leaf certificate and be accepted as the trusted identity.

Canonical disclosed the issue in late October 2026 after the vulnerability was referred by the Incus project. Fixed LXD and MicroCloud releases are now available, and administrators are strongly advised to update immediately.

The flaw is especially significant in infrastructure environments because LXD manages system containers and virtual machines, while MicroCloud coordinates clustered infrastructure. Compromise of an administrative identity can therefore extend beyond a single service and provide control over workloads or the host itself.

For CVE-2026-112816 detection, security teams should prioritize identifying internet- or network-accessible LXD and MicroCloud HTTPS APIs, reviewing trusted client certificates, and correlating successful certificate-based authentication with unexpected source systems or unusual administrative operations.

SOC Prime’s AI-Native Detection Intelligence Platform enables security teams to strengthen coverage for exploitation and post-compromise behavior across network, Linux, cloud, container, and identity telemetry.

Contact Sales

Click Explore Detections to access relevant detection content and hunting logic. To Detect CVE-2026-112816, defenders should combine vulnerable-version inventory with API access monitoring, certificate authentication telemetry, and suspicious administrative activity affecting containers, virtual machines, or cluster configuration.

CVE-2026-112816 analysis

CVE-2026-112816 is an improper certificate validation vulnerability in the HTTPS listener used by Canonical LXD and MicroCloud.

Both products can use mutual TLS to authenticate remote clients. Under normal mTLS behavior, the connecting client presents a certificate and proves ownership of the private key associated with the certificate used as the leaf of the TLS chain.

The problem arises because vulnerable LXD and MicroCloud implementations inspect more than that authenticated leaf certificate.

According to Canonical, remote API authentication logic compared all certificates presented by a client against entries in the trusted certificate store. However, TLS proves private-key possession only for the leaf certificate. Additional certificates in the presented chain are supplied by the client and do not independently prove ownership of their corresponding private keys.

This creates an authentication gap.

An attacker can generate a certificate and private key they control, use that certificate as the leaf, and append the public certificate of a trusted client elsewhere in the presented chain. The vulnerable server may find the trusted certificate and associate the connection with that trusted identity even though the attacker does not possess its private key.

The details for CVE-2026-112816 therefore show that exploitation depends primarily on two prerequisites:

• The attacker can reach the LXD or MicroCloud HTTPS API.
• The attacker possesses the public certificate of an identity already trusted by the target.

The trusted client’s private key is not required.

This distinction explains the vulnerability’s critical severity. Certificate-based authentication is expected to demonstrate possession of a secret private key, but the affected logic effectively allows possession of the public certificate alone to satisfy part of the trust decision.

A standalone LXD installation does not expose its remote HTTPS API by default. The Hacker News notes that LXD normally listens only on its local Unix socket unless an administrator enables network access, for example through the core.https_address configuration.

This means not every vulnerable LXD installation is remotely exploitable from another host.

Exposure becomes significantly higher when administrators enable the API across a management network or expose it to the internet.

MicroCloud presents another relevant attack scenario. Canonical states that an attacker who can intercept the public TLS certificate of a machine joining a MicroCloud cluster may subsequently authenticate as that joined member.

CVE-2026-112816 affects vulnerable Canonical LXD releases including 4.0.14, 5.0.10, 5.21.8, and 6.9 before their corresponding fixed releases.

Canonical lists these patched LXD versions:

• LXD 6.10.1 for the 6/stable channel
• LXD 5.21.9 for 5.21/stable
• LXD 5.0.11 for 5.0/stable
• LXD 4.0.15 for 4.0/stable

For MicroCloud, fixed versions are:

• MicroCloud 3.4.1 for 3/stable
• MicroCloud 2.1.5 for 2/stable

Ubuntu’s CVE record describes successful exploitation as allowing an unauthenticated attacker to authenticate as a trusted client and gain full access to the cluster and managed virtual machines through a crafted certificate chain.

The maximum CVSS score of 10.0 reflects network accessibility, low attack complexity, no required privileges, and no user interaction, combined with potentially high impact to confidentiality, integrity, and availability.

Impact ultimately depends on the privileges of the identity being impersonated.

A restricted identity may provide limited API capabilities. A highly privileged client or cluster identity can provide substantially greater access.

Canonical explicitly warns that impersonation of a privileged trusted user can result in root access to the host machine.

That can potentially allow an attacker to:

• Manage or modify containers and virtual machines.
• Access workloads managed through the compromised LXD environment.
• Modify infrastructure configuration.
• Create new workloads or alter existing ones.
• Interfere with availability.
• Access data available to the impersonated identity.
• Potentially reach the host with root-level privileges when sufficient permissions are available.

The flaw was originally identified in the related Incus project and then referred to Canonical, which confirmed that the same certificate-chain authentication problem affected LXD.

Incus describes the underlying issue similarly: the server requested client certificates without verifying the entire submitted chain, while trust checks iterated across every supplied peer certificate rather than restricting authentication to the actual leaf certificate. Incus addressed the issue in version 7.6.0.

The vulnerability appears to have existed for an extended period. Incus states that the equivalent authentication logic had been present since its initial release. Canonical’s public advisory does not provide an exact date for when the vulnerable LXD behavior was first introduced.

As of November 2, 2026, an independent CVE-2026-112816 PoC and lab reproduction have been published publicly. This represents a change from The Hacker News report published on November 1, which stated that no working exploit had yet been released. The public reproduction appeared after disclosure and is not the original vulnerability research.

Canonical and the referenced reporting have not indicated that the vulnerability has been exploited in real-world attacks.

The Hacker News reports that the issue was not known to be exploited as of the U.S. CISA assessment dated October 30 and was not included in CISA’s Known Exploited Vulnerabilities catalog at that time.

There are therefore no campaign-specific CVE-2026-112816 IOCs such as confirmed malicious IP addresses, domains, malware hashes, or known attacker infrastructure associated with exploitation.

Defenders should instead focus on vulnerability exposure and behavior.

Potential hunting opportunities include:

• Remote connections to LXD or MicroCloud HTTPS APIs from unexpected systems.
• Successful API authentication originating from networks not normally used by trusted administrators.
• A trusted certificate identity appearing from multiple unrelated source systems.
• Administrative API activity that does not match the expected owner of a certificate.
• Unexpected creation, deletion, or modification of containers and virtual machines.
• Changes to trusted certificate entries.
• New or altered cluster members.
• Unexpected changes to storage, networking, profiles, projects, or instance configuration.
• Privileged operations occurring shortly after unusual certificate-based authentication.
• API connections to management interfaces that were not intended to be remotely accessible.

Organizations should also inventory trusted certificates associated with former administrators, retired hosts, automation systems, and cluster members.

Because exploitation requires the public certificate rather than the private key, defenders should not treat the confidentiality of private keys alone as sufficient protection against this specific vulnerability.

Monitoring should also account for shared management networks.

An API that is not exposed directly to the public internet can still be exploitable by an attacker who has already gained a foothold on another system capable of reaching the management interface.

This makes lateral movement particularly relevant. A compromised workstation, server, CI/CD runner, management host, or cloud workload with network access to the LXD API could provide the position needed to exploit an otherwise internally exposed system.

CVE-2026-112816 Mitigation

Canonical recommends upgrading affected LXD and MicroCloud deployments to the latest fixed versions immediately.

For Snap-based deployments, administrators can update using:

sudo snap refresh lxd

and:

sudo snap refresh microcloud

After refreshing, verify the version actually installed rather than assuming that the update was applied successfully.

Canonical noted during disclosure that some LXD point releases were progressing from candidate to stable channels. Administrators should therefore explicitly confirm that their system is running one of the fixed versions.

The primary CVE-2026-112816 mitigation is upgrading to:

Product	Fixed version
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonical has not published a configuration-based workaround that fully eliminates the underlying authentication defect.

If immediate upgrading is impossible, restrict network access to the HTTPS API as aggressively as operational requirements allow.

Only authorized management hosts and trusted infrastructure should be able to establish connections to the listener.

For LXD installations that do not require remote management, administrators should evaluate whether the network API needs to remain enabled at all.

For environments that require remote access:

• Restrict the API using host or network firewalls.
• Permit connections only from dedicated management networks.
• Avoid exposing the API directly to the public internet.
• Use VPN or bastion-based administrative access where appropriate.
• Segment container and virtualization management infrastructure from user networks.
• Monitor all successful administrative API requests.
• Review trusted certificates and remove entries that are no longer necessary.

These controls reduce exposure but do not correct the vulnerable certificate-validation logic.

Organizations running MicroCloud should prioritize updating all relevant cluster members and review recent joining activity for unexpected systems or certificate identities.

Administrators should also review their trusted certificate stores.

Remove certificates belonging to decommissioned hosts, former administrators, unused automation systems, or identities that no longer require access.

Where suspicious activity is discovered, investigate the affected host and cluster before rotating credentials or modifying evidence.

Relevant sources of telemetry may include:

• LXD and MicroCloud service logs
• Linux system logs
• Firewall and network flow records
• Reverse proxy telemetry, if applicable
• Host EDR data
• Cloud network logs
• Cluster configuration and membership history
• Administrative change records

Look for unexpected instance creation, modification, deletion, snapshot activity, storage operations, networking changes, and configuration updates.

If exploitation is suspected and a privileged certificate identity was impersonated, defenders should treat potential host-level compromise seriously because Canonical confirms that root access may be possible depending on the victim identity’s permissions.

Incident responders should preserve relevant evidence and inspect the system for persistence, unauthorized accounts or certificates, modified services, new workloads, suspicious processes, and abnormal outbound network communication.

Organizations using Incus rather than Canonical LXD should separately update to Incus 7.6.0 or the relevant supported fixed release because the related project was affected by the same underlying certificate-chain trust issue.

Ubuntu also notes that its archive-packaged LXD versions for currently listed Ubuntu releases are either not shipped through the affected package path or not affected, while Canonical’s security guidance focuses on the Snap releases. Administrators should still verify the actual LXD distribution and version running in their environment rather than assuming exposure based solely on the Ubuntu release.

Disclaimer: Detection content may not be available for every CVE. Check the SOC Prime Platform for current coverage. If relevant detections are not yet available, check again as new threat intelligence and detection content are continuously added.