Canonical hat Patches für CVE-2026-112816 veröffentlicht – eine kritische Schwachstelle in den Produkten LXD und MicroCloud, die es einem Angreifer ermöglicht, sich als beliebiger vertrauenswürdiger TLS-Client zu authentifizieren und vollständigen Zugriff auf den Cluster und die verwalteten virtuellen Maschinen zu erhalten. Für die Ausnutzung genügt Netzwerkkonnektivität zum HTTPS-API und das öffentliche Zertifikat eines vertrauenswürdigen Clients – der private Schlüssel ist nicht erforderlich. Verfügt das kompromittierte Konto über Privilegien, kann der Angreifer Root-Zugriff auf die Host-Maschine erlangen. Administratoren von LXD und MicroCloud müssen die Snap-Pakete umgehend auf die fehlerbereinigten Versionen aktualisieren.
Mechanismus der Schwachstelle
LXD und MicroCloud verwenden mutual TLS für die Authentifizierung entfernter Clients: Der Client legt ein Zertifikat vor, und der Server prüft dessen Vorhandensein im Trust Store für vertrauenswürdige Identitäten. Das Problem lag darin, wie genau der Server diese Prüfung durchführte.
Laut dem Sicherheitshinweis von Canonical verglich die Authentifizierungslogik alle Zertifikate, die vom Client in der Kette übermittelt wurden, mit den Einträgen im Trust Store. Das TLS-Handshake bestätigt den Besitz des privaten Schlüssels jedoch nur für das erste Zertifikat in der Kette – das Leaf-Zertifikat. Die übrigen Zertifikate in der Kette werden vollständig vom Client kontrolliert.
Das bedeutet, dass ein Angreifer eine Zertifikatskette so konstruieren konnte, dass sein eigenes Leaf-Zertifikat an erster Stelle steht und das öffentliche Zertifikat eines vertrauenswürdigen Clients als Zwischenzertifikat eingebettet ist. Der Server fand das vertrauenswürdige Zertifikat in der Kette und akzeptierte die Verbindung im Namen dieses Clients, obwohl der Angreifer dessen privaten Schlüssel nicht besaß.
Betroffene Versionen und Patches
Laut der CVE-Seite von Ubuntu sind die folgenden Versionen von LXD von der Schwachstelle betroffen:
- LXD 4.0.14 (behoben in 4.0.15)
- LXD 5.0.10 (behoben in 5.0.11)
- LXD 5.21.8 (behoben in 5.21.9)
- LXD 6.9 (behoben in 6.10.1)
Für MicroCloud hat Canonical die fehlerbereinigten Versionen 2.1.5 und 3.4.1 veröffentlicht. Alle Patches tragen das Datum 29. Oktober 2026 und werden über die Snap-Kanäle ausgeliefert.
Die Schwachstelle wurde nicht von Canonical selbst entdeckt. Das Projekt Incus – ein von der Community entwickelter Fork von LXD – hat als erstes über das Problem berichtet, woraufhin Canonical bestätigte, dass derselbe Fehler auch LXD betrifft. Incus hat die Schwachstelle in Version 7.6.0 behoben – es handelt sich um ein eigenständiges Produkt, und seine Version ersetzt keine Updates für LXD oder MicroCloud.
Klarstellung zur Einstufung der Kritikalität
In einigen Veröffentlichungen wird der Schwachstelle ein CVSS-Score von 10.0 zugeschrieben. Der Sicherheitshinweis von Canonical für LXD und MicroCloud stuft das Problem jedoch lediglich als kritisch ein, ohne einen numerischen Wert anzugeben. Die Bewertung 10.0 findet sich explizit im Sicherheitshinweis von Incus für dieselbe Schwachstelle in der Zertifikatskette. Da es sich um dieselbe Fehlerklasse handelt, ist die Bewertung inhaltlich anwendbar, formal wurde sie jedoch vom Projekt Incus und nicht von Canonical vergeben.
Unterschiede in den Angriffsvektoren: LXD und MicroCloud
Die praktischen Angriffspfade unterscheiden sich je nach Produkt. Für einen autonomen LXD-Server erfordert der Angriff die Netzwerkerreichbarkeit des HTTPS-API, das standardmäßig nicht offen ist – es lauscht nur auf dem lokalen Socket, sofern der Administrator den Parameter core.https_address nicht aktiviert hat.
MicroCloud, das mehrere Maschinen mit LXD zu einem gemeinsamen Cluster verbindet, schafft einen zusätzlichen Vektor: Nach Angaben von Canonical kann ein Angreifer, der in der Lage ist, das öffentliche TLS-Zertifikat eines Knotens im Moment seines Beitritts zum Cluster abzufangen, sich später im Namen dieses Knotens authentifizieren. Dadurch wird der Prozess des Hinzufügens neuer Cluster-Mitglieder zu einem besonders sensiblen Punkt.
Bei der Beseitigung der Schwachstelle sollten Installationen mit offenen API-Listenern und Umgebungen, in denen Cluster-Erweiterungsoperationen durchgeführt werden, Priorität haben.
Status der Ausnutzung
Nach aktuellem Kenntnisstand wurden keine Hinweise auf eine aktive Ausnutzung der Schwachstelle festgestellt. CVE-2026-112816 ist nicht im CISA-Katalog Known Exploited Vulnerabilities aufgeführt, und öffentliche Exploits wurden nicht veröffentlicht. Das Fehlen im KEV-Katalog ist jedoch für sich genommen kein Beweis dafür, dass keine Ausnutzung stattgefunden hat.
Empfehlungen
Zur Beseitigung der Schwachstelle:
- Aktualisieren Sie die Snap-Pakete:
sudo snap refresh lxdundsudo snap refresh microcloud - Überprüfen Sie nach dem Update die tatsächlich installierte Version – zum Zeitpunkt der Veröffentlichung des Sicherheitshinweises von Canonical befanden sich die Patches für LXD in der Phase der schrittweisen Überführung vom Kanal
candidateinstable - Incus-Nutzer müssen auf Version 7.6.0 aktualisieren
Es existiert kein konfigurationsseitiger Workaround – darauf weisen sowohl Canonical als auch das Incus-Projekt ausdrücklich hin. Bis zur Installation des Updates besteht die einzige Maßnahme zur Risikoreduzierung darin, den Netzwerkzugriff auf den HTTPS-Listener auf vertrauenswürdige Hosts zu beschränken.
Früher haben wir bereits über kritische Schwachstellen im Ubuntu-Ökosystem berichtet – etwa die pedit-COW-Rechteausweitung im Linux-Kernel. CVE-2026-112816 unterscheidet sich dadurch, dass der Angriff nicht auf den Kernel, sondern auf die Orchestrierungsebene von Containern und virtuellen Maschinen zielt, was bei erfolgreicher Ausnutzung sofortigen Zugriff auf den gesamten Cluster ermöglicht.
Angesichts des Fehlens von Workarounds und des potenziellen Umfangs einer Kompromittierung – von Zugriff auf virtuelle Maschinen bis hin zu Root auf dem Host – stellt das Aktualisieren der Snap-Pakete von LXD und MicroCloud auf die fehlerbereinigten Versionen die einzige vollständige Schutzmaßnahme dar und sollte ohne Verzögerung erfolgen, insbesondere auf Installationen mit offenem Netzwerk-API.
