Eine kritische Schwachstelle in Canonicals Virtualisierungs- und Containerplattform LXD sowie in MicroCloud erlaubte es Angreifern, sich als vertrauenswürdiger Client anzumelden, ohne dessen privaten Schlüssel zu besitzen. Die Lücke trägt die Kennung CVE-2026-112816 und die Höchstbewertung CVSS 10.0. Canonical hat korrigierte Versionen veröffentlicht, wie The Hacker News und eine Sicherheitsmitteilung im Ubuntu-Forum berichten.
Wie der Fehler funktioniert
LXD und MicroCloud erlauben den Zugriff auf ihre APIs über gegenseitiges TLS. Der Client weist sich dabei mit einem Zertifikat aus. Als vertrauenswürdig gilt er, wenn sein Zertifikat im Trust Store des Servers hinterlegt ist. Der Fehler lag in der Prüfung: Der Server verglich jedes Zertifikat, das der Client mitschickte, mit dem Trust Store. Eine TLS-Verbindung beweist aber nur, dass der Client den privaten Schlüssel für das erste Zertifikat der Kette besitzt. Der Rest der Kette ist frei wählbar.
Ein Angreifer konnte also das öffentliche, nicht geheime Zertifikat eines vertrauenswürdigen Clients hinter sein eigenes hängen, und der Server akzeptierte ihn als diesen Client. War das übernommene Konto privilegiert, war laut Canonical sogar Root-Zugriff auf den Host möglich.
Wer betroffen ist
Für einen Angriff braucht es Netzwerkzugriff auf die HTTPS-API und das öffentliche Zertifikat eines vertrauenswürdigen Clients. Ein einzelner LXD-Server stellt die API standardmäßig nicht ins Netz, er lauscht nur auf einem lokalen Socket, solange niemand die Einstellung core.https_address aktiviert. Bei MicroCloud, das mehrere LXD-Rechner zu einem Cluster verbindet, gibt es eine besondere Schwachstelle: Wer das öffentliche Zertifikat eines Mitglieds beim Beitritt zum Cluster abfängt, kann sich danach als dieses Mitglied anmelden.
Korrigiert ist der Fehler in den Snap-Versionen LXD 6.10.1, 5.21.9, 5.0.11 und 4.0.15 sowie MicroCloud 3.4.1 und 2.1.5. Die LXD-Pakete im Ubuntu-Archiv sind laut Canonical nicht betroffen oder werden nicht ausgeliefert. Entdeckt hat den Fehler das Projekt Incus, ein Community-Fork von LXD, das ihn in Version 7.6.0 behoben hat.
Was zu tun ist
Öffentliche Hinweise auf Angriffe gibt es bisher nicht. Laut einer Einschätzung der US-Behörde CISA vom 30. Oktober ist keine Ausnutzung bekannt, ein funktionierender Exploit wurde nicht veröffentlicht. Admins sollten dennoch mit „snap refresh lxd“ und „snap refresh microcloud“ aktualisieren und danach die tatsächlich installierte Version prüfen, weil die Korrekturen zum Zeitpunkt der Mitteilung noch ausgerollt wurden. Einen Workaround nennt Canonical nicht. Bis zum Update hilft nur, den Netzwerkzugriff auf die API einzuschränken.
Was jetzt zu tun ist
Wer LXD oder MicroCloud betreibt, sollte die bereitgestellten Updates zeitnah einspielen und prüfen, welche Nutzer Zugriff auf die Verwaltungsschnittstellen haben. Gerade Container-Plattformen gelten als Grenze zwischen Arbeitslasten, eine Lücke dort betrifft deshalb oft mehr als nur ein einzelnes System.


