Een kritieke fout in Canonical’s LXD en MicroCloud maakte het mogelijk voor een aanvaller om in te loggen als een vertrouwde client zonder de privésleutel van die client te bezitten. Hiervoor moest de aanvaller de HTTPS‑API over het netwerk kunnen bereiken en het publieke certificaat van de vertrouwde client hebben.
Eens binnen zou de aanvaller optreden als die client, met toegang tot de cluster en de virtuele machines. Als het geïmiteerde account bevoordeeld is, kon de aanvaller volgens Canonical “root‑toegang tot de hostmachine” verkrijgen.
De kwetsbaarheid, geregistreerd als CVE-2026-112816, heeft een maximale CVSS‑score van 10.0. Canonical heeft voor beide producten gefixeerde versies uitgebracht.
Hoe de fout werkt
LXD en MicroCloud laten externe clients hun API’s benaderen via mutual TLS (mTLS), een opzet waarbij de client een certificaat presenteert om zijn identiteit te bewijzen. Een client wordt als vertrouwd beschouwd wanneer zijn certificaat in de truststore van de server staat, de lijst met identiteiten die de server accepteert.
De fout zat in de manier waarop de server dat certificaat controleerde. De server vergeleek elk certificaat dat de client stuurde met de truststore, maar een TLS‑verbinding bewijst slechts dat de client de privésleutel bezit voor het eerste certificaat in de keten, het bladcertificaat. De rest van de keten kan elke willekeurige keten zijn die de client heeft bijgevoegd.
Een aanvaller kon dus het publieke certificaat van een vertrouwde client — dat niet geheim is — pakken, het achter zijn eigen certificaat in de keten plaatsen, en de server accepteerde hen vervolgens als die vertrouwde client.
Wie is getroffen
Voor het misbruik van de fout zijn twee dingen nodig: netwerktoegang tot de HTTPS‑API en het publieke certificaat van een client die de server al vertrouwt.
Een op zichzelf staande LXD‑server stelt die API niet standaard bloot. Hij luistert enkel op een lokale socket tenzij een beheerder de netwerk‑API inschakelt met de instelling core.https_address.
MicroCloud, dat meerdere machines met LXD tot één cluster verbindt, heeft een specifiek zwak punt. Canonical zei dat een aanvaller die het publieke certificaat van een lid kan onderscheppen terwijl dat lid aan de cluster toetreedt, daarna als dat lid kan inloggen.
Het CVE‑record vermeldt LXD 4.0.14, 5.0.10, 5.21.8 en 6.9 als getroffen, telkens in versies vóór de daarvoor uitgebrachte fixes. Canonical noemt de volgende gefixeerde snap‑versies:
| Product | Snap kanaal | Gefixeerde versie |
|---|---|---|
| LXD | 6/stable | 6.10.1 |
| LXD | 5.21/stable | 5.21.9 |
| LXD | 5.0/stable | 5.0.11 |
| LXD | 4.0/stable | 4.0.15 |
| MicroCloud | 3/stable | 3.4.1 |
| MicroCloud | 2/stable | 2.1.5 |
De bug begon niet bij Canonical. Het Incus‑project, dat als community fork van LXD ontstond, rapporteerde de fout en Canonical bevestigde dat LXD er ook door getroffen werd. Incus verholp dezelfde fout in versie 7.6.0.
De Ubuntu‑archivepakketten van LXD worden door Canonical als niet‑getroffen of niet‑geleverd vermeld, dus de gefixeerde uitgaven zijn de snaps.
Er is geen openbaar teken dat de fout al in het wild werd misbruikt. Het CVE‑record bevat een beoordeling van het Amerikaanse CISA, gedateerd 30 oktober, dat de fout niet bekend staat als geëxploiteerd; hij staat niet op CISA’s lijst van Known Exploited Vulnerabilities en er is geen werkende exploit gepubliceerd.
Wat te doen
Werk LXD en MicroCloud bij naar de gefixeerde versies. Bij een snap‑installatie voer uit: sudo snap refresh lxd en sudo snap refresh microcloud.
Canonical gaf aan dat de gefixeerde puntreleases van LXD nog van het candidate‑kanaal naar stable werden uitgerold ten tijde van hun advies, controleer dus na de refresh de versie die je werkelijk hebt in plaats van ervan uit te gaan dat de fix al binnen is.
Het advies van Canonical geeft geen tijdelijke workaround voor LXD. Omdat de aanval netwerktoegang tot de API vereist, verkleint het beperken van wie die API kan bereiken het risico totdat je bijgewerkt hebt. Het Incus‑project, dat dezelfde fout rapporteerde, zei dat er geen configuratie‑oplossing is en dat de enige tijdelijke maatregel is om netwerktoegang tot de listener te beperken.
Incus‑gebruikers moeten naar 7.6.0 upgraden, waarin deze fout samen met 17 andere beveiligingsproblemen is opgelost.
