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, 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. Canonical's advisory sets the bar for attack: reach the LXD web API, and hold the public certificate of a trusted client.
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 with its list of trusted ones. But only the leaf certificate proves ownership of the signing key. 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, 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 and then pose as that member. And depending on whose identity was borrowed, the attacker may gain root access to the host machine.
Who found it?
Canonical says the issue was referred to it by the Incus project, 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. Canonical released fixed snaps on October 29, 2026: 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.
- It lets an attacker authenticate as any trusted TLS client whose public certificate they hold.
- Fixed snaps were released on October 29.
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. On snap installs that is
sudo snap refresh lxdandsudo 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.