> ## Content Index > Fetch the complete content index at: https://thecyberstories.com/llms.txt > Use this file to discover other available public pages before exploring further. # A borrowed certificate could unlock whole LXD clusters. Update now - URL: https://thecyberstories.com/lxd-critical-certificate-flaw/ - Published: 2026-11-03T04:23:07.000Z - Updated: 2026-11-03T04:23:07.000Z - Description: A flaw rated 10 out of 10 in Canonical's LXD and MicroCloud let an attacker log in as a trusted client using only that client's public certificate. Fixes shipped on October 29. Here's how it worked, and the single command that matters. - Author: Raja Sekhar Thota - Tags: Incidents, #csv-6ae9612abb92540f93998e3d, #Import 2026-11-03 21:46 ## In brief LXD is Canonical's tool for running containers and virtual machines on Linux, and MicroCloud builds small private clouds on top of it. A flaw disclosed on October 30 let an attacker log in to them as a trusted client using only that client's public certificate, the part that is meant to be safe to share. It is rated [10, Critical](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/112xxx/CVE-2026-112816.json?ref=thecyberstories.com), the highest score possible. Fixes are out. ## What happened? The CVE record says the flaw lets [an unauthenticated attacker authenticate as any trusted client and gain full access to the cluster and managed virtual machines](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/112xxx/CVE-2026-112816.json?ref=thecyberstories.com). Canonical's advisory sets the bar for attack: reach the LXD web API, and hold the [public certificate of a trusted client](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com). ## How a public certificate became a key LXD lets trusted machines log in with certificates instead of passwords. Each machine has a private key, kept secret, and a public certificate, shared freely. Proving you hold the private key is what proves who you are. The bug was in how LXD checked. When a client connected, LXD compared [all the certificates it sent](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com) with its list of trusted ones. But [only the leaf certificate proves ownership of the signing key](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com). The others in the chain are just paperwork. So an attacker could [place someone else's trusted public certificate as an intermediate in the chain](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com), and LXD would see a familiar face and let them in. Think of a guard who checks that your ID card is in the stack you hand over, without checking which card has your photo. In MicroCloud it was easier still: an attacker could [intercept the public certificate of a new member joining the cluster](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com) and then pose as that member. And depending on whose identity was borrowed, the attacker [may gain root access to the host machine](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com). ## Who found it? Canonical says the issue [was referred to it by the Incus project](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com), the community fork of LXD, and confirmed it affects LXD too. That's open source working as it should: one project's finding protecting another's users. ## Who is affected? The CVE record lists [LXD 6.9, 5.21.8, 5.0.10 and 4.0.14 before their fixed releases](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/112xxx/CVE-2026-112816.json?ref=thecyberstories.com). Canonical released fixed snaps on [October 29, 2026](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com): LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 2.1.5 and 3.4.1. ## What is confirmed? - The flaw is rated [10, Critical](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/112xxx/CVE-2026-112816.json?ref=thecyberstories.com). - It lets an attacker [authenticate as any trusted TLS client](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com) whose public certificate they hold. - Fixed snaps were [released on October 29](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com). ## What remains unknown? - Whether anyone has exploited it. We have seen no report of attacks so far. - How many LXD and MicroCloud APIs are reachable from the internet. ## Why it matters LXD often runs the machines that run everything else. Full access to the cluster means every container and virtual machine on it. With a public explanation and a 10/10 score, we wouldn't expect the quiet to last. ## What readers should do - **Update now.** Canonical [urges all users to update immediately](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com). On snap installs that is `sudo snap refresh lxd` and `sudo snap refresh microcloud`, then confirm the version. - **Keep the LXD API off the internet.** Allow it only from management networks. The attack needs network reach. - **Review the trust store.** Remove certificates for machines and people who no longer need access, and check recent API activity for unfamiliar actions. - **If you joined MicroCloud members recently** over an untrusted network, review what those identities have done since. ## Sources - [CVE-2026-112816: Improper certificate validation in the HTTPS listener in LXD (CVE record, published October 30, 2026)](https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/112xxx/CVE-2026-112816.json?ref=thecyberstories.com) - [Security advisory: Critical vulnerability found in Canonical LXD and MicroCloud (Canonical, Ubuntu Discourse, October 2026)](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557?ref=thecyberstories.com)