Deze editie draait om één lek, maar wel een zwaar: in Canonical LXD en MicroCloud kan een aanvaller zich als vertrouwde client aanmelden zonder de bijbehorende private key. Het lek heeft de maximale score van 10,0, er zijn patches, misbruik is nog niet gemeld.
LXD en MicroCloud: aanvaller meldt zich als vertrouwde client aan zonder private key
| Kwetsbaarheid | Omzeiling van authenticatie door onjuiste controle van clientcertificaatketens in de HTTPS-listener van Canonical LXD (kwetsbaar tot en met 4.0.14, 5.0.10, 5.21.8 en 6.9) en MicroCloud. De Incus-fork heeft hetzelfde probleem |
| CVE-nummer | CVE-2026-112816 |
| CVSS-score | 10,0 |
| Actief misbruikt | Nee. Volgens een CISA-beoordeling in het CVE-record van 30 oktober is misbruik niet bekend, staat het lek niet in de KEV-catalogus en is er geen publieke exploit |
| Patch beschikbaar | Ja. LXD 6.10.1, 5.21.9, 5.0.11 en 4.0.15, MicroCloud 3.4.1 en 2.1.5, Incus 7.6.0. Een workaround ontbreekt, beperk tot die tijd de netwerktoegang tot de API |
Hoe kan de kwetsbaarheid misbruikt worden?
LXD en MicroCloud gebruiken wederzijdse TLS: een client toont een certificaat en de server vertrouwt die als het certificaat in de trust store staat. Volgens de advisory van Canonical vergeleek de server alle door de client aangeleverde certificaten met die store, terwijl alleen het eerste certificaat in de keten bewijst dat de client de bijbehorende sleutel bezit. Een aanvaller hangt het publieke certificaat van een vertrouwde client achter een eigen certificaat en wordt als die client geaccepteerd. Dat publieke certificaat is niet geheim. Bij MicroCloud ligt het zwakke punt bij het toetreden tot een cluster: wie het certificaat van een toetredend lid onderschept, kan zich als dat lid aanmelden. Het lek is gemeld door het Incus-project, zo meldt The Hacker News.
Wat kan het gevolg zijn?
De aanvaller handelt als de nagebootste client, met toegang tot het cluster en de virtuele machines. Bij een bevoorrechte client kan dat volgens Canonical root-toegang tot de host opleveren. Een voorwaarde is netwerktoegang tot de HTTPS-API. Een losstaande LXD-installatie luistert standaard alleen op een lokale socket, tenzij een beheerder de netwerk-API heeft ingeschakeld met core.https_address. Clusters, MicroCloud-omgevingen en hosts waar de API breed bereikbaar is lopen dus het meeste risico. De Ubuntu-archiefpakketten van LXD zijn niet getroffen, de fix zit in de snaps.
Wat moeten IT-beheerders nu doen?
Werk LXD en MicroCloud bij met sudo snap refresh lxd en sudo snap refresh microcloud, en controleer daarna de geïnstalleerde versie. Canonical meldt dat de LXD-releases nog van het candidate- naar het stable-kanaal werden uitgerold, dus een refresh op het stable-kanaal levert mogelijk nog niet direct de gepatchte versie op. Zoek uit welke hosts de API via het netwerk aanbieden en sluit die af voor alles buiten je beheernetwerk totdat de patch er staat. Gebruik je Incus, ga dan naar versie 7.6.0.
