Er is een kritieke beveiligingsfout ontdekt in LXD en MicroCloud van Canonical: CVE-2026-112816 met een maximale CVSS-score van 10.0. Het probleem maakt trusted client impersonation mogelijk, waarbij een aanvaller zich kan voordoen als een client die de server al vertrouwt—zonder de private key van die client te bezitten.
Concreet kan de aanvaller, nadat de beveiligde API is benaderd en een publieke certificaatwaarde van een vertrouwde client is gevonden, inloggen onder die identiteit. Als die client over verhoogde rechten beschikt, kan dit zelfs leiden tot root-toegang tot de host. Er is dus weinig ruimte om te wachten.
Wat is er precies mis in LXD en MicroCloud?
LXD en MicroCloud gebruiken een aanpak met mutual TLS voor toegang tot hun HTTPS-API’s. In zo’n opzet bewijst de client zijn identiteit via een certificaat en vertrouwt de server op een “trust store”: de lijst met certificaten die hij accepteert.
De kwetsbaarheid zit in de manier waarop de server controleert of het certificaat echt bij de vertrouwde set hoort. De kern is dat TLS niet alleen garandeert dat de client de private key van het eerste (leaf) certificaat beheerst, maar dat de rest van de certificaatketen door de client kan worden samengesteld.
Daardoor kan een aanvaller een publiek certificaat van een vertrouwde client nemen (dus iets wat niet geheim hoeft te zijn) en het zodanig in de TLS-keten “achteraan” plaatsen dat de server denkt dat de client die vertrouwde identiteit gebruikt.
Trusted client impersonation: welke stappen zijn nodig?
Om de aanval uit te voeren zijn volgens Canonical twee voorwaarden belangrijk:
- Netwerktoegang tot de HTTPS API van LXD of de componenten van MicroCloud.
- Een publiek certificaat van een client die de server al vertrouwt (dus aanwezig in de trust store).
Als aan die voorwaarden is voldaan, kan de aanvaller zich als die client gedragen. Dat is extra ernstig omdat die “veronderstelde client” toegang kan hebben tot de clusteromgeving en de virtuele machines.
Wie is getroffen en hoe weet je of jouw versie kwetsbaar is?
De CVE-registratie noemt onder meer de volgende LXD-versies als getroffen (elk vóór de daaropvolgende fix-versies): 4.0.14, 5.0.10, 5.21.8 en 6.9.
Voor MicroCloud geldt hetzelfde uitgangspunt: de fixed snap-versies zijn leidend. Canonical geeft aan dat Ubuntu’s archiefpakketten van LXD niet standaard getroffen zouden zijn of niet zijn geleverd, en dat de oplossing vooral via snaps moet komen.
Er is bovendien een relatie met het Incus-project: Incus meldde de fout als eerste in dezelfde generatie producten. Incus heeft de kwetsbaarheid opgelost in 7.6.0; Canonical bevestigde dat LXD erdoor geraakt wordt.
Waarom de aanval in de praktijk nog steeds gevaarlijk is
Hoewel niet ieder systeem automatisch blootstaat, kan de combinatie van netwerktoegang en een trusted certificaat genoeg zijn voor misbruik. Zeker in omgevingen waar een beheeromgeving of API’s extern bereikbaar zijn, wordt de kans groter dat een aanvaller de benodigde route kan vinden.
Canonical merkt daarnaast op dat er geen publiek bewijs is dat de fout al actief is misbruikt. In de CISA-beoordeling (gedateerd 30 oktober) staat dat er geen bekende exploitatie is en dat de kwetsbaarheid niet op CISA’s Known Exploited Vulnerabilities-lijst staat. Er is ook geen werkende exploit openbaar gemaakt.
Dat neemt niet weg dat “nog niet misbruikt” geen garantie is—met CVSS 10.0 en een plausibele techniek kan dit snel veranderen.
Snelle aanpak: patch LXD en MicroCloud
De primaire maatregel is helder: update naar de vaste versies. Canonical adviseert voor snaps:
- sudo snap refresh lxd
- sudo snap refresh microcloud
Let wel op de releaseflow: Canonical gaf aan dat de fix in de tijd van publicatie nog aan het uitrollen was van candidate naar stable. Controleer daarom na de refresh welke versie daadwerkelijk draait, in plaats van alleen te vertrouwen op de aanwezigheid van een update.
Geen tijdelijke workaround? Beperk vooral netwerktoegang
Voor LXD noemt Canonical geen tijdelijke “configuratie-omweg” die de kwetsbaarheid volledig neutraliseert. Omdat de aanval netwerktoegang tot de API vereist, is beperken van bereik de beste praktische reductie.
Voor Incus gebruikers geldt volgens de berichtgeving hetzelfde idee: er is geen configuratiefix die het probleem oplost; het advies is om de toegang tot de luisterende componenten te beperken tot alleen noodzakelijke netwerken of hosts.
Voor een standalone LXD-server is het belangrijk om te weten dat de HTTPS API standaard niet op het netwerk wordt blootgesteld. Die luistert alleen op een lokale socket, tenzij een beheerder de network API expliciet inschakelt via de core.https_address-instelling.
Met andere woorden: als je deze instelling gebruikt om API-toegang over het netwerk mogelijk te maken, dan moet je extra snel patchen en bereik afschermen.
Wat je vandaag nog kunt controleren
Als je LXD of MicroCloud in gebruik hebt, kun je gericht actie ondernemen:
- Inventariseer welke LXD-versies draaien en of die binnen de genoemde getroffen bandbreedtes vallen.
- Verifieer welke snap-versies actief zijn na refresh (candidate/stable kan verschillen per systeem).
- Check de netwerkexposure van de HTTPS API: wie kan erbij en vanaf waar?
- Beperk truststore-blootstelling waar mogelijk: hoe meer vertrouwde clients, hoe groter de potentiële waarde van certificaatinformatie.
Wil je daarnaast een bredere context over netwerkgerichte aanvallen en hoe snel bereik een factor kan worden, dan zijn vergelijkbare analyses rond Network-layer DDoS stijgt sterk nuttig om te begrijpen hoe verdediging vaak begint bij het afbakenen van toegangswegen.
Conclusie
CVE-2026-112816 maakt trusted client impersonation mogelijk in LXD en MicroCloud en krijgt terecht een CVSS 10.0. De techniek is eenvoudig in concept: een aanvaller gebruikt netwerktoegang tot de API en een publiek certificaat van een vertrouwde client om in te loggen als die client—zonder diens private key.
De juiste reactie is daarom: update LXD en MicroCloud naar de gefixte snap-versies en beperk de netwerktoegang tot de API totdat de patch overal is doorgevoerd. Hiermee voorkom je dat een kwetsbaarheid met root-implicaties jouw virtuele omgeving kan raken.
Bron: https://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.html
