[Security Advisory] CVSS 10.0 Authentication Bypass in Canonical LXD & MicroCloud (CVE-2026-112816) — Impact & Remediation Guide

Advisory ID: LUCKVM-SA-2026-1031-LXD

Published: October 31, 2026

Severity: Critical — CVSS v4.0 10.0 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H)

Identifiers: CVE-2026-112816 (GHSA-99jp-jwmc-65p4 / GHSA-pq55-m3w3-jh54, CWE-295)

Affected Products: Canonical LXD (4.0, 5.0, 5.21, and 6 tracks) and Canonical MicroCloud (2 and 3)

1. Executive Summary

Canonical has disclosed a maximum-severity (CVSS v4.0 10.0) authentication bypass vulnerability tracked as CVE-2026-112816 affecting the HTTPS listener in Canonical LXD and MicroCloud.

Due to improper certificate chain validation (CWE-295), an unauthenticated remote attacker who reaches the LXD HTTPS API and possesses a trusted client's public certificate (without needing any password or private key) can authenticate as that trusted client via a crafted certificate chain. Successful exploitation grants full administrative control over the LXD cluster, all managed system containers and virtual machines, and can lead to root compromise on the underlying host.

Platform Reassurance: LuckVM's underlying KVM cloud infrastructure, Dedicated Servers, and Bulk-IP Proxmox VE / VMware Bare-Metal Hosts are not affected. Workloads using standard Docker or native Proxmox VE LXC containers are also unaffected. However, customers who have deployed LXD (with the remote HTTPS listener enabled) or MicroCloud on their LuckVM instances or bare-metal servers must take immediate action.

2. Technical Root Cause (CWE-295: Improper Certificate Validation)

• How the mTLS Bypass Works: Remote clients authenticate to the LXD HTTPS API using mutual TLS (mTLS) by presenting a client certificate chain. Cryptographically, only the first certificate in the chain (the leaf certificate) proves that the connecting client holds the matching private key. However, affected versions of LXD compared every certificate in the client-supplied chain against the local trust store. Consequently, an attacker can generate a self-signed leaf certificate, append a trusted client's public certificate further down the chain, and be accepted by LXD as that trusted administrator.

• MicroCloud Cluster Exposure: In MicroCloud deployments, an attacker can intercept the public certificate of a member node joining a cluster and use it to authenticate as that cluster member.

• Prerequisite for Network Exploitation: By default, LXD listens only on a local Unix socket. Hosts are vulnerable to remote network exploitation whenever the HTTPS listener is enabled (core.https_address is configured) or when operating in a LXD/MicroCloud cluster.

3. Affected & Patched Versions

Ironically, CVE-2026-112816 specifically impacts the point releases (4.0.14, 5.0.10, 5.21.8, and 6.9.0–6.10.0) that many administrators recently installed to address earlier host-root vulnerabilities (CVE-2026-87799, CVE-2026-85185, CVE-2026-85526):

(Note: The community fork Incus, which originally referred this flaw to Canonical, is tracked separately under GHSA-xg75-xf37-cph9—ensure Incus installations are also updated.)

4. Remediation & Hardening Instructions

Step 1: Refresh the LXD and MicroCloud Snaps (Do Not Rely on apt)

Canonical distributes LXD exclusively as a Snap package on supported Ubuntu releases; running apt upgrade will not patch your LXD installation. Take a precautionary Snapshot in the LuckVM Dashboard, then run:

sudo snap refresh lxd
sudo snap refresh microcloud

Step 2: Verify the Installed Version (Critical Channel Lag Warning)

Independent checks on October 31, 2026 revealed that while 6/stable serves the patched 6.10.1 build, the 5.21, 5.0, and 4.0 stable channels in the Snap Store may still serve vulnerable builds, or a configured snap refresh --hold (which can delay updates for up to 90 days) may prevent the upgrade. Always verify your active version immediately after refreshing:

snap list lxd

Confirm that the installed version matches 6.10.1, 5.21.9, 5.0.11, or 4.0.15.

Step 3: Audit & Restrict the LXD HTTPS API Listener

Check whether your LXD daemon is exposing the HTTPS API to the network:

lxc config get core.https_address

1. If you do not require remote API access (Single-Host Setup): Disable the network listener immediately so LXD binds strictly to the local Unix socket:

   Bash

    

   lxc config unset core.https_address
   

2. If you operate a LXD/MicroCloud Cluster or require remote API access: Especially if your release track (5.21, 5.0, or 4.0) has not yet received the patched build on the stable channel, immediately restrict access to the LXD HTTPS port (typically TCP 8443) using firewall rules (ufw, iptables, or nftables) so that only trusted cluster peer IPs and internal management bastion hosts can connect. Never expose core.https_address (8443) to 0.0.0.0/0 on the public internet.

Step 4: Audit the LXD Trust Store

Review all client certificates currently trusted by your LXD daemon or cluster:

lxc config trust list

Remove any stale, unrecognized, or overly broad client certificates, and inspect your system and LXD access logs for anomalous authentication events.

If you need assistance configuring firewall rules, taking instance snapshots, or migrating containerized workloads onto dedicated LuckVM Bulk-IP Proxmox VE / VMware Bare-Metal Hosts, please contact our 24/7 engineering team via the LuckVM Support Portal.

LuckVM Infrastructure & Security Team