lee1981 (@lee1981b) on X

What it is

CVE-2026-112816 is an authentication flaw (CWE-295) in the HTTPS management API of LXD and MicroCloud. Canonical, as CNA, rates it 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). The CVE was published on 30 October 2026. It credits Stéphane Graber, and Canonical acknowledges the Incus project's referral. The post is a CyberForge "CVE of the Day #093" with an evidence cutoff of 2 November 2026.

How it works

The application trust check compared client-supplied certificate material beyond the identity whose private-key possession the TLS exchange proved. A caller with a trusted client's public certificate can therefore be accepted as that identity, and API operations inherit its permissions. Canonical says host-root access is possible depending on the victim's privilege. For MicroCloud, the public certificate of a joining member can be intercepted and later used to impersonate the joined member.

Preconditions / Affected

The attacker needs network reach to the HTTPS API and the public certificate of a trusted identity. No private key is needed.

Standalone LXD listens on a local Unix socket by default, so exposure depends on core.https_address and cluster.https_address. A private address can still be reachable from an untrusted internal position.

Affected LXD ranges and fixes (CNA data):

• 4.0.14 up to 4.0.15: fixed in 4.0.15 (4.0/stable)
• 5.0.10 up to 5.0.11: fixed in 5.0.11 (5.0/stable)
• 5.21.8 up to 5.21.9: fixed in 5.21.9 (5.21/stable)
• 6.9.0 up to 6.10.1: fixed in 6.10.1 (6/stable)

LXD 6.10.0 is still affected. MicroCloud is fixed in 2.1.5 (2/stable) and 3.4.1 (3/stable). The earliest affected MicroCloud version was not established.

What to do

Check each member, including offline and standby ones, for version, revision and track:

snap list lxd
snap list microcloud

Check the serving daemon and listener settings through the local socket:

lxc --force-local query /1.0
lxc --force-local config get core.https_address
lxc --force-local config get cluster.https_address

Then:

1. Restrict the sources that can reach the management API, keeping cluster traffic and recovery access.
2. Preserve LXD events, network records and package history before changes where feasible.
3. Run snap refresh to the fixed release for the installed track. Canonical's notice gives this instruction, and the post describes the rollout as progressive.
4. Confirm the serving build on every member, not just the installed snap or a newer lxc client.
5. Decide separately whether past activity was malicious. A patch does not undo unauthorised changes.

For hunting, look for a trusted identity used from an unexplained source or at a time its owner cannot account for. A successful bypass may not produce a failed-authentication event or add a trust-store entry. The post suggests ATT&CK T1190 (if Internet-facing) or T1210 (internal lateral movement) as conditional mappings.

Caveats

• Exploitation: the post found no primary incident confirmation. CISA's ADP entry (30 October) lists Exploitation "none", Automatable "yes", Technical Impact "total".
• KEV: no exact entry in catalog 2026.10.30.
• EPSS: 0.303% (23.145th percentile) on 1 November 2026.
• Other ratings: Ubuntu's tracker rates priority Medium, and NVD shows Deferred. The Ubuntu archive-package table is not snap clearance.
• Public repositories claim a PoC (one created 31 October, another 1 November). The author did not run or verify them.
• The related Incus advisory has no CVE ID and its own scope. Its claims are not confirmed for LXD.
• The Canonical GHSA returned 404, and no patch commit was independently verified.
• The author ran none of the commands or fixes.