Canonical hat eine kritische Sicherheitslücke in LXD und MicroCloud geschlossen. Über CVE-2026-112816 kann sich ein Angreifer gegenüber der HTTPS-API als bereits vertrauenswürdiger Client ausgeben, ohne dessen privaten Schlüssel zu besitzen. Die Schwachstelle erreicht im Bewertungssystem CVSS 4.0 den Maximalwert 10,0.
Nach erfolgreicher Ausnutzung handelt der Angreifer mit den Berechtigungen des imitierten Clients. Damit kann er auf den Cluster und die darin verwalteten virtuellen Maschinen zugreifen. Gehört das verwendete Zertifikat zu einem privilegierten Client, ist laut Canonical auch Root-Zugriff auf die Host-Maschine möglich.
Der Maximalwert beschreibt allerdings nicht jede Installation gleichermaßen. Für einen Angriff müssen zwei Bedingungen erfüllt sein: Die HTTPS-API muss über das Netzwerk erreichbar sein, und der Angreifer benötigt das öffentliche Zertifikat eines Clients, dem der Server bereits vertraut. Bei einem eigenständigen LXD-System ist die Netzwerkschnittstelle standardmäßig nicht exponiert. Das ändert sich erst, wenn ein Administrator sie über core.https_address aktiviert.
Der Server prüfte das falsche Glied der Zertifikatskette
LXD und MicroCloud verwenden gegenseitiges TLS, um entfernte Clients an ihren APIs zu authentifizieren. Ein Client präsentiert dabei ein Zertifikat; der Server gleicht dessen Identität mit seinem Trust Store ab. Üblicherweise soll die TLS-Verbindung belegen, dass der Client den zum Zertifikat gehörenden privaten Schlüssel kontrolliert.
Wie die fehlerhafte Zertifikatsprüfung umgangen wird
Die Grafik zeigt die Voraussetzungen und den Ablauf, über den ein eigenes Leaf-Zertifikat zusammen mit dem öffentlichen Zertifikat eines vertrauenswürdigen Clients zur Client-Imitation führt.
Der Fehler lag nicht in der Verschlüsselung, sondern in der anschließenden Zuordnung der Identität. Der Server verglich jedes vom Client übermittelte Zertifikat der Kette mit seinem Trust Store. Die TLS-Verbindung beweist jedoch nur den Besitz des privaten Schlüssels für das erste Zertifikat, das sogenannte Leaf-Zertifikat. Weitere Zertifikate in der übermittelten Kette kann der Client selbst anhängen.
Ein Angreifer kann deshalb eine Verbindung mit einem eigenen Leaf-Zertifikat aufbauen und dahinter das öffentliche Zertifikat eines vertrauenswürdigen Clients platzieren. Findet der fehlerhafte Abgleich dieses Zertifikat im Trust Store, ordnet der Server die Verbindung dem vertrauenswürdigen Client zu. Der Angreifer benötigt also durchaus einen privaten Schlüssel für sein eigenes Zertifikat, aber nicht den geheimen Schlüssel des Opfers.
Betroffenheit hängt an API-Zugriff und Betriebsmodell
Als betroffen nennt der CVE-Eintrag die LXD-Versionen 4.0.14, 5.0.10, 5.21.8 und 6.9, jeweils vor dem nachfolgenden korrigierten Release. Canonical stellt die Fixes als Snaps bereit: LXD 4.0.15, 5.0.11, 5.21.9 und 6.10.1. Für MicroCloud wurden die Versionen 2.1.5 und 3.4.1 veröffentlicht.
Ubuntu-Archivpakete von LXD werden in der Meldung als nicht betroffen beziehungsweise nicht ausgeliefert geführt. Für die praktisch relevanten Installationen konzentriert sich die Aktualisierung damit auf die Snap-Pakete.
Bei einem alleinstehenden LXD-Server reduziert die lokale Standardeinstellung die erreichbare Angriffsfläche erheblich. Wer die HTTPS-API nie für das Netzwerk aktiviert hat, bietet den beschriebenen entfernten Einstieg nicht an. Sobald die API jedoch für Verwaltungszugriffe erreichbar ist, entscheidet die vorgelagerte Netzbegrenzung darüber, welche Systeme überhaupt einen Ausnutzungsversuch starten können.
MicroCloud bringt eine andere operative Situation mit: Das Produkt verbindet mehrere LXD-Systeme zu einem Cluster. Canonical zufolge kann ein Angreifer das öffentliche Zertifikat eines Mitglieds beim Beitritt zum Cluster mitschneiden und sich anschließend als dieses Mitglied authentifizieren. Ein öffentliches Zertifikat ist zwar kein Geheimnis. Durch den Implementierungsfehler wird sein Besitz hier dennoch zu einem Teil der Angriffsvoraussetzung.
Updates ausführen und die installierte Version kontrollieren
Betreiber sollten LXD mit sudo snap refresh lxd und MicroCloud mit sudo snap refresh microcloud aktualisieren. Entscheidend ist anschließend die tatsächlich installierte Versionsnummer. Zum Zeitpunkt des Canonical-Hinweises wurden die korrigierten LXD-Ausgaben noch schrittweise vom Candidate- in den Stable-Kanal überführt. Ein ausgeführter Refresh-Befehl allein garantiert daher nicht, dass der jeweilige Fix bereits auf dem System angekommen ist.
Canonical nennt für LXD keinen temporären Konfigurations-Workaround. Bis zum Update sollte der Netzwerkzugriff auf den HTTPS-Endpunkt auf tatsächlich benötigte und vertrauenswürdige Hosts beschränkt werden. Auch das Incus-Projekt, das die Schwachstelle entdeckt und gemeldet hat, sieht keine Konfigurationsänderung, die den Programmfehler behebt. Incus-Nutzer müssen auf Version 7.6.0 wechseln; diese Ausgabe schließt neben diesem Fehler 17 weitere Sicherheitsprobleme.
Zum Stichtag 30./31. Oktober 2026 gibt es keinen öffentlichen Hinweis auf eine Ausnutzung. CISA führt die Schwachstelle nicht in ihrem Katalog der nachweislich ausgenutzten Sicherheitslücken. Ein funktionsfähiger öffentlicher Exploit ist ebenfalls nicht bekannt. Das bedeutet: Die Lücke ist technisch schwerwiegend und theoretisch ausnutzbar, beobachtete Angriffe sind bislang aber nicht belegt.
CVSS 10,0 ist nicht dasselbe wie universelle Erreichbarkeit
Die operative Priorität ergibt sich aus einer Kombination, die der reine CVSS-Wert nicht abbildet: Exponierung der API, Verfügbarkeit eines vertrauenswürdigen öffentlichen Zertifikats und Privilegien der imitierten Identität. Bei lokal gebundenen Standalone-Systemen fehlt bereits der erste Baustein. Bei vernetzten Verwaltungs- oder MicroCloud-Umgebungen können dagegen alle drei Voraussetzungen zusammenkommen – mit entsprechend weitreichenden Folgen.
Der Vorfall macht damit vor allem eine unscheinbare Grenze in der Zertifikatsprüfung sichtbar. Mutual TLS schützt nur dann die erwartete Identität, wenn die Anwendung exakt das Zertifikat bewertet, dessen Schlüsselbesitz die Verbindung tatsächlich bewiesen hat. Für Betreiber folgt daraus eine nüchterne Reihenfolge: Erreichbarkeit prüfen, Netzwerkzugriff begrenzen, Snap aktualisieren und den Patchstand anhand der Versionsnummer verifizieren.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
