Max-Severity LXD Bug Lets Attackers Pose as Your Trusted Admin
Canonical fixed CVE-2026-112816 (CVSS 10.0) in LXD and MicroCloud: a crafted certificate chain lets anyone who can reach the HTTPS API impersonate a trusted client, no private key needed.
Canonical has patched a CVSS 10.0 flaw in LXD and MicroCloud that lets an attacker log in to the management API as a trusted client without ever holding that client’s private key. All they need is network access to the HTTPS listener and the trusted client’s public certificate, which isn’t secret. The Hacker News reports the bug was found by the Incus project, the community fork of LXD, and Canonical confirmed LXD was hit too.
For defenders
The flaw: CVE-2026-112816 (CVSS 4.0 score 10.0, CWE-295 improper certificate validation). LXD and MicroCloud trust a client when its certificate is in the server’s trust store, but the server checked every certificate in the chain the client sent, not just the leaf. A TLS handshake only proves the client holds the leaf’s private key, so a crafted chain carrying a trusted client’s certificate further up passed the check. Canonical says a privileged impersonated account can mean root on the host; at minimum it’s full control of the cluster and its VMs.
Affected and fixed:
| Product | Fixed in |
|---|---|
| LXD 6 | 6.10.1 |
| LXD 5.21 LTS | 5.21.9 |
| LXD 5.0 LTS | 5.0.11 |
| LXD 4.0 LTS | 4.0.15 |
| MicroCloud 3 / 2 | 3.4.1 / 2.1.5 |
| Incus | 7.6.0 (also fixes 17 other security issues) |
Exposure: standalone LXD only listens on a local Unix socket unless core.https_address is set, so the risk is hosts and clusters with the HTTPS API enabled. MicroCloud is the bigger worry: Canonical says anyone who captures a member’s public certificate during cluster join can then log in as that member. Ubuntu archive packages aren’t affected; the snaps are.
Exploitation: none reported. Not on CISA KEV, EPSS about 0.3%. The Hacker News said no working exploit had been published; our CVE data now shows one GitHub repository reported as a proof of concept, so assume that changes fast. Canonical offers no workaround for LXD; until you patch, restrict who can reach the API port.
Advisories: Canonical, Ubuntu CVE page, Incus GHSA-xg75-xf37-cph9.
What it means for you
LXD and MicroCloud are tools companies and hobbyists use to run lots of small virtual servers on their own hardware. If you don’t run them, there’s nothing to do. If you do, this bug is about as bad as it gets on paper: someone who can reach the management port could act as one of your trusted admin machines and take over every container and VM it controls.
Do this now
- Run
sudo snap refresh lxdandsudo snap refresh microcloud, then check the version: Canonical says the fixed LXD releases were still moving from candidate to stable when it published. - Run
lxc config get core.https_addresson each host; if it returns an address you don’t need, unset it. - Firewall the LXD/MicroCloud API port (8443 by default) to known admin hosts only until every node is patched.
- Incus users: upgrade to 7.6.0; there’s no configuration fix.
CVE at a glance
- CVSS
- 10 Critical (v4.0)
- EPSS
- 0.3% chance of exploitation in the next 30 days (higher than 23.1% of CVEs)
- Exploited in the wild
- Not on CISA’s KEV list
- Public exploit
- Yes, reported in 1 GitHub repository
Data from NVD, FIRST EPSS and CISA KEV, refreshed automatically. We report whether public exploit code exists but never link to it: fake proof-of-concepts that infect researchers are common.