LXD CVE-2026-112816: Authentication Bypass via Public Certificate Chains

TL;DR

---

A critical authentication bypass vulnerability, CVE-2026-112816, has been disclosed in Canonical LXD’s HTTPS API.
According to the OpenCVE record, it carries a CVSS v4.0 base score of 10.0 and was published on October 30, 2026.
LXD is a system container and virtual machine manager, operating independently from Docker. Deployments running solely Docker are unaffected.
While running Ubuntu does not inherently make a system vulnerable, checking for LXD incorrectly can produce false positives due to packaging wrappers.

How Attackers Authenticate Without Private Keys

LXD’s remote API relies on mutual TLS (mTLS), where connecting clients present a certificate to prove their identity.
In standard mutual authentication, the client proves possession of the private key corresponding to its leaf certificate during the TLS handshake. Any subsequent certificates in the chain—such as intermediate CA certificates—are supplied to bridge trust to a root anchor.

According to Canonical’s security advisory, vulnerable LXD versions checked every certificate throughout the presented chain against its trust store of authorized client certificates.
Due to this verification flaw, an attacker could create a leaf certificate signed by their own private key, prove possession of that leaf key during the handshake, and append a trusted client’s public certificate into the chain.
Because LXD matched any certificate in the chain against its trust store, it authorized the connection as the trusted client—even though the attacker never possessed the trusted client’s private key.
Public certificates are not secret credentials, meaning presentation alone cannot ensure authenticity. No cryptographic cracking is required.

flowchart TD
    A["Attacker creates a leaf certificate with their own private key"] --> B["Attacker appends a trusted client's public certificate to the chain"]
    B --> C["TLS handshake proves possession only of the attacker's leaf key"]
    C --> D["LXD matches every certificate in the chain against its trust store"]
    D --> E["Appended public certificate matches trust store, granting trusted client access"]

The severity of an exploit depends on the privileges granted to the impersonated client.
Canonical notes that depending on the victim’s permission level, an attacker could gain root access to the host system.
In MicroCloud deployments, intercepting a cluster member’s public TLS certificate could allow an attacker to authenticate as that cluster member.

Patched and Affected Versions

Canonical’s security advisory (released October 29, 2026) lists the following patched releases:

Snap Channel	Package	Patched Version
6/stable	lxd	6.10.1
5.21/stable	lxd	5.21.9
5.0/stable	lxd	5.0.11
4.0/stable	lxd	4.0.15
3/stable	microcloud	3.4.1
2/stable	microcloud	2.1.5

The CVE record lists affected versions as 4.0.14, 5.0.10, 5.21.8, and 6.9.
While version 6.10.0 is not explicitly listed in that CVE record, the patch for the 6.x series is 6.10.1, meaning 6.x deployments should update to 6.10.1.

On Ubuntu’s CVE tracker, the priority is categorized as Medium.
Debian packages (deb) for lxd are marked “Not in release” on Ubuntu 26.10, 26.04, 24.04, and 22.04, and “Not affected” on 20.04 and earlier, meaning updates apply to Snap packages.

This issue originally originated from Incus, a community fork of LXD.
Incus Security Advisory GHSA-xg75-xf37-cph9 rates the issue at CVSS v3.1 10.0 and provides patched version 7.6.0, noting that no configuration-based workaround exists.
The Incus advisory leaves its CVE field blank, and Incus release logs show no 7.0.x maintenance release following 7.6.0 as of November 2, 2026.

Availability of Public Certificates and Attack Prerequisites

Canonical specifies two prerequisites for an exploit: network access to the HTTPS API, and possession of a trusted client’s public certificate.
However, relying on the confidentiality of public certificates is dangerous.

The Incus advisory explains that server certificates are returned during any TLS handshake without prior authorization, and appending them to the certificate chain could grant unauthorized access to internal database endpoints.
Furthermore, trusted client certificates can be retrieved via the certificate API by authorized entities or extracted from servers that the client has previously connected to.
While Canonical’s advisory does not explicitly confirm whether the exact same retrieval paths apply to LXD, administrators should not assume an installation is secure simply because client certificates are not publicly hosted.

In contrast, network exposure is straightforward to verify.
According to LXD official documentation, LXD listens strictly on a local Unix socket by default, rejecting external network traffic.
LXD accepts remote connections only when core.https_address is explicitly configured.
The port 8443 cited in official documentation is merely an example; administrators must check their active configuration rather than assuming default port numbers.

How to Safely Check for LXD on Your Server

Servers dedicated solely to Docker containers do not need updates unless LXD was installed separately.
Verification should always begin with snap list.
Ubuntu 24.04 includes the lxd-installer package, which installs /sbin/lxc and /sbin/lxd.
As its package description states (“Wrapper to install lxd snap on demand”), this wrapper is designed to install LXD via Snap only when requested.
If this package is present, running command -v lxd will return a path if /sbin is in your PATH, even if LXD itself is not installed.
Examining the package scripts reveals that invoking the wrapper without an existing Snap triggers an installation prompt.
To avoid inadvertently starting an installation, do not run lxc or lxd before confirming whether the Snap is present.

# Check if LXD or MicroCloud Snaps are installed
snap list lxd microcloud

# Check if the HTTPS API is exposed (run only if LXD Snap is installed)
lxc config get core.https_address

# Inspect active listening ports
sudo ss -ltnp | grep -E 'lxd|microcloud'

If snap list produces no matching entries, neither LXD nor MicroCloud is installed via Snap on the system.
If the Snap package is installed, update to a patched release even if core.https_address is currently unset:

sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud

When Canonical published the advisory, patched packages were being rolled out gradually from candidate to stable channels.
Because refresh commands may report success before the latest build propagates to your specific region or channel, always verify the final version number with snap list.
Until the update is applied, firewall rules should restrict access to the HTTPS port strictly to trusted IP addresses—a mitigation highlighted in the Incus advisory.

PoC Status and Active Exploitation

According to CISA data mirrored on OpenCVE, active exploitation is rated as “none,” and the vulnerability is not listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog.
However, attack automation is rated as “yes.”

On exploit indexing service Sploitus, a repository titled dehasoft-tr/cve-2026-112816 is flagged as a PoC.
Reviewing its README reveals that the repository contains only a basic verification and update script for Snap packages, not functional exploit code.
Therefore, that specific repository does not serve as evidence of an exploit in the wild.

Impact When Hosting Providers Run LXD on the Hypervisor

For VPS tenants, a significant challenge arises if the hosting provider uses LXD on the underlying host hypervisor.
In that architecture, updating the guest operating system or Docker containers inside your VPS will not address vulnerabilities in the host-level management API.
Furthermore, tenants have no direct means to inspect whether the host utilizes LXD or has applied security patches.

ConoHa VPS FAQ states that its infrastructure runs on KVM hypervisors.
Because CVE-2026-112816 affects LXD’s API rather than KVM itself, the presence of KVM does not indicate an inherent vulnerability.
However, because LXD can also manage KVM virtual machines, KVM adoption alone does not rule out LXD in the management plane.
The FAQ does not mention LXD, and ConoHa VPS news releases from October 2026 onward contain no announcements regarding LXD or CVE-2026-112816 as of November 2, 2026.

As a practical reference for monitoring provider advisories during separate past security incidents, announcements from ConoHa VPS illustrate this distinction:

Date	ConoHa Announcement	Tenant Verification Action
October 19, 2026	Suspension of new orders due to CVE-2026-99999	Response to a VM escape vulnerability affecting hypervisors
October 23, 2026	Service resumed on patched host nodes	Existing host nodes were scheduled for sequential maintenance, with specific maintenance windows sent to registered tenant emails
October 24, 2026	Emergency maintenance temporarily halting new orders	Orders halted at 13:40 without specifying a completion time or CVE number
October 30, 2026	Advisory regarding CVE-2026-98432 mitigation	Tenants needed to update the guest kernel inside their VPS and reboot

In host-level incidents like CVE-2026-99999, running uname -r inside a VPS yields only the guest kernel version, revealing nothing about the host hypervisor.
In such cases, individual maintenance notification emails serve as the primary confirmation source.
Conversely, vulnerabilities like CVE-2026-98432 target the guest OS kernel directly, requiring tenants to patch and reboot their own systems.
When reviewing provider security advisories, tenants must distinguish between hypervisor-level maintenance and self-administered guest updates.