LXD und MicroCloud: Kritische Lücke erlaubt Anmeldung als fremder Client
Canonical schließt in LXD und MicroCloud die kritische Lücke CVE-2026-112816. Wer die HTTPS-API erreicht und das öffentliche Zertifikat eines vertrauten Clients kennt, kann sich als dieser anmelden und je nach Rechten Root auf dem Host erlangen. Updates kommen über die Snaps.
Canonical hat eine kritische Sicherheitslücke in LXD und MicroCloud geschlossen. Die als CVE-2026-112816 geführte Schwachstelle erlaubt es, sich gegenüber der HTTPS-API als beliebiger vertrauter Client auszugeben, sofern das öffentliche Zertifikat dieses Clients bekannt ist. Das Incus-Projekt bewertet die gleiche Lücke mit dem CVSS-Höchstwert 10.0. Korrigierte Snaps stehen seit dem 29.10.2026 bereit.
Betroffen sind vor allem Installationen, deren API über das Netz erreichbar ist, sowie MicroCloud-Cluster. Ein Standalone-LXD, das nur auf dem lokalen Socket lauscht, ist deutlich weniger exponiert. Wer LXD oder MicroCloud mit erreichbarer Netz-API betreibt, sollte das Update heute einspielen und nicht auf das nächste Wartungsfenster warten.
Was ist passiert?
LXD und MicroCloud authentifizieren entfernte Clients über Mutual TLS. Ein Client gilt als vertraut, wenn sein Zertifikat im Trust Store des Servers steht. Laut Canonical verglich die Prüflogik jedoch alle vom Client gesendeten Zertifikate der Kette mit dem Trust Store. Nur das erste Zertifikat, das Leaf, beweist im TLS-Handshake den Besitz des privaten Schlüssels. Den Rest der Kette bestimmt der Client selbst.
Ein Angreifer konnte deshalb das öffentliche Zertifikat eines vertrauten Clients als Zwischenzertifikat hinter sein eigenes hängen und wurde als dieser Client akzeptiert. Den privaten Schlüssel des Opfers braucht er dafür nicht. Gemeldet wurde der Fehler vom Incus-Projekt, das als Community-Fork aus LXD hervorgegangen ist. Canonical bestätigte, dass auch LXD betroffen ist. Incus behebt die Lücke in Version 7.6.0 (GHSA-xg75-xf37-cph9, veröffentlicht am 29.10.2026). Der CVE-Eintrag erschien am 30.10.2026.
Wer ist betroffen?
Der CVE-Eintrag nennt LXD 4.0.14, 5.0.10, 5.21.8 und 6.9 jeweils vor den korrigierten Versionen. Für einen Angriff braucht es zwei Dinge: Netzzugang zur HTTPS-API und das öffentliche Zertifikat eines Clients, dem der Server bereits vertraut. Ein eigenständiges LXD lauscht standardmäßig nur auf einem lokalen Socket. Die Netz-API ist erst aktiv, wenn Admins core.https_address gesetzt haben.
Bei MicroCloud kommt ein besonderer Punkt hinzu: Laut Canonical kann ein Angreifer das öffentliche Zertifikat eines Clustermitglieds abfangen, während es dem Cluster beitritt, und sich danach als dieses Mitglied anmelden. Die LXD-Pakete im Ubuntu-Archiv sind laut Ubuntu Security nicht betroffen oder nicht enthalten. Die Korrekturen kommen daher über die Snaps.
Wie kritisch ist das?
Die Folgen hängen von den Rechten des imitierten Clients ab. Canonical warnt, dass ein Angreifer im ungünstigsten Fall Root-Zugriff auf den Host erhalten kann. Der CVE-Text spricht von vollem Zugriff auf den Cluster und die verwalteten virtuellen Maschinen. Nach Angaben von The Hacker News gibt es bislang keine bekannte Ausnutzung, die Lücke steht nicht im Katalog CISA KEV und ein öffentlicher Exploit ist nicht bekannt. Canonical nennt keinen Workaround. Den Zugang zur API auf vertrauenswürdige Systeme zu beschränken, senkt das Risiko, ersetzt das Update aber nicht.
Was sollten Admins jetzt tun?
- Inventar prüfen: Auf welchen Hosts laufen LXD oder MicroCloud, in welchem Kanal, und ist
core.https_addressgesetzt? Die installierte Version zeigtsnap list lxd microcloud. - Aktualisieren mit
sudo snap refresh lxdundsudo snap refresh microcloud. Korrigiert sind lxd 6.10.1 (6/stable), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable), 4.0.15 (4.0/stable) sowie microcloud 3.4.1 (3/stable) und 2.1.5 (2/stable). - Version nach dem Refresh erneut prüfen. Canonical verteilt die Point-Releases schrittweise von candidate nach stable, ein Refresh liefert daher nicht auf jedem Host sofort den Fix.
- Die HTTPS-API per Firewall auf bekannte Verwaltungssysteme begrenzen, bis alle Hosts aktualisiert sind.
- Incus-Installationen auf Version 7.6.0 oder neuer bringen.
Einordnung für Unternehmen
LXD wird häufig für interne Testumgebungen, Build-Systeme und kleine Private Clouds eingesetzt. Gerade dort ist die Netz-API oft eingeschaltet, damit mehrere Admins oder Automatisierungen zugreifen können. Öffentliche Client-Zertifikate gelten nicht als geheim und liegen auf vielen Rechnern. Das macht die Voraussetzung für einen Angriff vergleichsweise niedrig. Teams sollten die Lücke deshalb wie einen direkten Root-Zugang zur Virtualisierungsschicht behandeln und priorisieren. Die jüngsten Funktionen von LXD 6.10 hat S-EDV in einer eigenen News zusammengefasst.
