CVE-2026-112816: Kritische LXD- und MicroCloud-Authentifizierungsumgehung ermöglicht Cluster-Übernahme

Canonical hat Sicherheitsupdates veröffentlicht, die CVE-2026-112816 adressieren, eine kritische Schwachstelle beim Umgehen der Authentifizierung, die LXD und MicroCloud betrifft. Der Fehler hat eine maximale CVSS-Punktzahl von 10,0 und kann einem nicht authentifizierten Remote-Angreifer ermöglichen, sich als vertrauenswürdiger TLS-Client auszugeben, ohne den privaten Schlüssel dieses Clients zu besitzen.

Ein erfolgreicher Angriff kann Zugang zur LXD- oder MicroCloud-API mit den dem nachgeahmten Identitätsrechten zugewiesenen Berechtigungen gewähren. Wenn die vertrauenswürdige Identität über ausreichende Berechtigungen verfügt, kann ein Angreifer vollständigen Zugang zum Cluster, zu verwalteten virtuellen Maschinen und potenziell auf Root-Ebene zum zugrunde liegenden Host erhalten.

Die Schwachstelle ergibt sich aus einer unsachgemäßen Validierung von Client-Zertifikatketten, die für die gegenseitige TLS-Authentifizierung verwendet werden. Anstatt nur das Blatt-Zertifikat zu authentifizieren, dessen zugehöriger privater Schlüssel vom Client nachgewiesen wird, vergleichen verwundbare Implementierungen jedes im Client-gesteuerten Kette bereitgestellte Zertifikat mit vertrauenswürdigen Zertifikaten.

Ein Angreifer, der auf die HTTPS-API zugreifen und das öffentliche Zertifikat eines bereits vertrauenswürdigen Clients erhalten kann, kann dieses Zertifikat hinter einem vom Angreifer kontrollierten Blatt-Zertifikat anfügen und als die vertrauenswürdige Identität akzeptiert werden.

Canonical hat das Problem Ende Oktober 2026 bekannt gegeben, nachdem die Schwachstelle vom Incus-Projekt weitergeleitet wurde. Erneuerte LXD- und MicroCloud-Versionen sind jetzt verfügbar, und Administratoren wird dringend empfohlen, sofort zu aktualisieren.

Der Fehler ist besonders in Infrastrukturbereichen signifikant, da LXD Systemcontainer und virtuelle Maschinen verwaltet, während MicroCloud eine koordinierte Cluster-Infrastruktur ermöglicht. Der Kompromiss einer administrativen Identität kann sich daher über einen einzelnen Dienst hinaus erstrecken und die Kontrolle über Arbeitslasten oder den Host selbst ermöglichen.

Für die Erkennung von CVE-2026-112816 sollten Sicherheitsteams die Identifizierung von Internet- oder netzwerkzugänglichen LXD- und MicroCloud-HTTPS-APIs priorisieren, vertrauenswürdige Client-Zertifikate überprüfen und die erfolgreiche zertifikatbasierte Authentifizierung mit unerwarteten Quellsystemen oder ungewöhnlichen administrativen Operationen korrelieren.

Die AI-Native Detection Intelligence Platform von SOC Prime ermöglicht Sicherheitsteams, die Abdeckung für Ausbeutung und Verhalten nach dem Kompromiss in Bezug auf Netzwerk-, Linux-, Cloud-, Container- und Identitätstelemetrie zu stärken.

Vertrieb kontaktieren

Klicken Sie auf Erkunden der Erkennungen, um relevanten Erkennungsinhalt und Jagdlogik zuzugreifen. Um CVE-2026-112816 zu erkennen, sollten Verteidiger verwundbare Versionsinventarisierung mit API-Zugriffsüberwachung, Zertifikatauthentifizierungstelemetrie und verdächtiger administrativer Aktivität, die Container, virtuelle Maschinen oder Cluster-Konfiguration betrifft, kombinieren.

CVE-2026-112816 Analyse

CVE-2026-112816 ist eine unzureichende Zertifikatvalidierungs-Schwachstelle im HTTPS-Listener, der von Canonical LXD und MicroCloud verwendet wird.

Beide Produkte können gegenseitiges TLS zur Authentifizierung von Remote-Clients verwenden. Unter normalem mTLS-Verhalten präsentiert der sich verbindende Client ein Zertifikat und beweist den Besitz des privaten Schlüssels, der mit dem als Blatt der TLS-Kette verwendeten Zertifikat verbunden ist.

Das Problem entsteht, weil anfällige LXD- und MicroCloud-Implementierungen mehr als nur das authentifizierte Blatt-Zertifikat inspizieren.

Laut Canonical vergleicht die Authentifizierungslogik der Remote-API alle vom Client präsentierten Zertifikate mit den Einträgen im vertrauenswürdigen Zertifikatspeicher. TLS beweist jedoch den Besitz des privaten Schlüssels nur für das Blatt-Zertifikat. Zusätzliche Zertifikate in der präsentierten Kette werden vom Client geliefert und beweisen nicht unabhängig den Besitz ihrer zugehörigen privaten Schlüssel.

Dies schafft eine Authentifizierungslücke.

Ein Angreifer kann ein Zertifikat und einen privaten Schlüssel, die er kontrolliert, generieren, dieses Zertifikat als das Blatt verwenden und das öffentliche Zertifikat eines sonstwo in der präsentierten Kette vertrauenswürdigen Clients anhängen. Der verwundbare Server könnte das vertrauenswürdige Zertifikat finden und die Verbindung mit dieser vertrauenswürdigen Identität assoziieren, obwohl der Angreifer nicht dessen privaten Schlüssel besitzt.

Die Einzelheiten zu CVE-2026-112816 zeigen daher, dass die Ausbeutung hauptsächlich von zwei Voraussetzungen abhängt:

• Der Angreifer kann das LXD- oder MicroCloud-HTTPS-API erreichen.
• Der Angreifer besitzt das öffentliche Zertifikat einer bereits vom Ziel vertrauten Identität.

Der private Schlüssel des vertrauenswürdigen Clients ist nicht erforderlich.

Diese Unterscheidung erklärt die kritische Schwere der Schwachstelle. Zertifikatbasierte Authentifizierung soll den Besitz eines geheimen privaten Schlüssels nachweisen, aber die betroffene Logik erlaubt effektiv, dass allein der Besitz des öffentlichen Zertifikats einen Teil der Vertrauensentscheidung erfüllt.

Eine eigenständige LXD-Installation setzt ihre Remote-HTTPS-API standardmäßig nicht aus. Die Hacker News stellen fest, dass LXD normalerweise nur auf seinem lokalen Unix-Socket hört, es sei denn, ein Administrator aktiviert den Netzwerkzugang, zum Beispiel über die core.https_address-Konfiguration.

Das bedeutet, dass nicht jede verwundbare LXD-Installation von einem anderen Host aus remote ausnutzbar ist.

Die Exposition wird erheblich höher, wenn Administratoren die API über ein Verwaltungsnetzwerk hinweg aktivieren oder sie dem Internet aussetzen.

MicroCloud bietet ein weiteres relevantes Angriffsszenario. Canonical erklärt, dass ein Angreifer, der das öffentliche TLS-Zertifikat einer Maschine abfangen kann, die einem MicroCloud-Cluster beitritt, anschließend als das beigetretene Mitglied authentifiziert werden kann.

CVE-2026-112816 betrifft anfällige Canonical-LXD-Versionen einschließlich 4.0.14, 5.0.10, 5.21.8 und 6.9 vor ihren entsprechenden behobenen Versionen.

Canonical listet diese gepatchten LXD-Versionen auf:

• LXD 6.10.1 für den 6/stable-Kanal
• LXD 5.21.9 für 5.21/stable
• LXD 5.0.11 für 5.0/stable
• LXD 4.0.15 für 4.0/stable

Für MicroCloud sind behobene Versionen:

• MicroCloud 3.4.1 für 3/stable
• MicroCloud 2.1.5 für 2/stable

Der CVE-Eintrag von Ubuntu beschreibt erfolgreiche Ausbeutung als das Ermöglichen eines Angreifers ohne Authentifizierung, sich als vertrauenswürdiger Client zu authentifizieren und über eine präparierte Zertifikatkette vollständigen Zugriff auf den Cluster und auf verwaltete virtuelle Maschinen zu erhalten.

Die maximale CVSS-Bewertung von 10,0 spiegelt die Netzwerkzugänglichkeit, geringe Angriffskomplexität, keine erforderlichen Berechtigungen und keine Benutzerinteraktion wider, zusammen mit potenziell hohem Einfluss auf Vertraulichkeit, Integrität und Verfügbarkeit.

Die Auswirkungen hängen letztlich von den Berechtigungen der verkleideten Identität ab.

Eine eingeschränkte Identität kann begrenzte API-Fähigkeiten bieten. Ein hochprivilegierter Client oder eine Cluster-Identität kann deutlich größeren Zugriff bieten.

Canonical warnt ausdrücklich davor, dass die Verkleidung eines privilegierten vertrauenswürdigen Benutzers in Root-Zugang zur Host-Maschine resultieren kann.

Das kann es einem Angreifer potenziell ermöglichen:

• Container und virtuelle Maschinen zu verwalten oder zu modifizieren.
• Zugriff auf Arbeitslasten, die durch die kompromittierte LXD-Umgebung verwaltet werden.
• Die Infrastrukturkonfiguration zu ändern.
• Neue Arbeitslasten zu erstellen oder vorhandene zu ändern.
• Die Verfügbarkeit zu stören.
• Auf Daten zuzugreifen, die der verkleideten Identität zur Verfügung stehen.
• Potentiell auf den Host mit Root-Level-Berechtigungen zuzugreifen, wenn ausreichende Berechtigungen vorhanden sind.

Die Schwachstelle wurde ursprünglich im verwandten Incus-Projekt identifiziert und dann an Canonical weitergeleitet, das bestätigte, dass dasselbe Problem bei der Authentifizierung durch die Zertifikatskette LXD betraf.

Incus beschreibt das zugrunde liegende Problem ähnlich: Der Server forderte Client-Zertifikate an, ohne die gesamte übermittelte Kette zu verifizieren, während Vertrauensprüfungen über jedes bereitgestellte Peer-Zertifikat iterierten, anstatt die Authentifizierung auf das eigentliche Blatt-Zertifikat zu beschränken. Incus adressierte das Problem in Version 7.6.0.

Die Schwachstelle scheint über einen längeren Zeitraum bestanden zu haben. Incus stellt fest, dass die gleichwertige Authentifizierungslogik seit ihrer ersten Veröffentlichung vorhanden war. Die öffentliche Beratung von Canonical gibt kein genaues Datum an, ab wann das verwundbare LXD-Verhalten erstmals eingeführt wurde.

Seit dem 2. November 2026 wurden ein unabhängiger CVE-2026-112816 PoC und eine Laboreproduktion öffentlich veröffentlicht. Dies stellt eine Änderung gegenüber dem Bericht von The Hacker News dar, der am 1. November veröffentlicht wurde und besagte, dass noch kein funktionierender Exploit veröffentlicht worden sei. Die öffentliche Reproduktion erschien nach Offenlegung und ist nicht die ursprüngliche Sicherheitsforschung.

Canonical und die referenzierten Berichte haben nicht angegeben, dass die Schwachstelle in realen Angriffen ausgenutzt wurde.

The Hacker News berichtet, dass das Problem mit Stand der Beurteilung der U.S. CISA am 30. Oktober nicht als ausgenutzt bekannt war und zu diesem Zeitpunkt nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen enthalten war.

Daher gibt es keine kampagnenspezifischen CVE-2026-112816 IOCs wie bestätigte bösartige IP-Adressen, Domains, Malware-Hashes oder bekannte Angreiferinfrastrukturen, die mit der Ausbeutung in Verbindung gebracht werden.

Verteidiger sollten sich stattdessen auf die Exposition der Schwachstelle und das Verhalten konzentrieren.

Potenzielle Jagdmöglichkeiten umfassen:

• Remote-Verbindungen zu LXD- oder MicroCloud-HTTPS-APIs von unerwarteten Systemen.
• Erfolgreiche API-Authentifizierung, die von Netzwerken ausgeht, die normalerweise nicht von vertrauenswürdigen Administratoren verwendet werden.
• Eine vertrauenswürdige Zertifikatsidentität, die aus mehreren nicht zusammenhängenden Quellsystemen stammt.
• Administrative API-Aktivitäten, die nicht dem erwarteten Eigentümer eines Zertifikats entsprechen.
• Unerwartetes Erstellen, Löschen oder Modifizieren von Containern und virtuellen Maschinen.
• Änderungen an vertrauenswürdigen Zertifikatseinträgen.
• Neue oder veränderte Cluster-Mitglieder.
• Unerwartete Änderungen an Speicher, Netzwerken, Profilen, Projekten oder Instanzkonfiguration.
• Privilegierte Operationen, die kurz nach ungewöhnlicher zertifikatbasierter Authentifizierung auftreten.
• API-Verbindungen zu Verwaltungsoberflächen, die nicht für den Fernzugriff gedacht waren.

Organisationen sollten auch vertrauenswürdige Zertifikate inventarisieren, die mit ehemaligen Administratoren, ausgemusterten Hosts, Automatisierungssystemen und Cluster-Mitgliedern verbunden sind.

Da die Ausbeutung das öffentliche Zertifikat erfordert, anstatt des privaten Schlüssels, sollten Verteidiger nicht die Vertraulichkeit privater Schlüssel allein als ausreichenden Schutz gegen diese spezifische Schwachstelle betrachten.

Überwachung sollte auch gemeinsame Verwaltungsnetzwerke berücksichtigen.

Ein API, das nicht direkt dem öffentlichen Internet ausgesetzt ist, kann immer noch von einem Angreifer ausgenutzt werden, der bereits eine Position auf einem anderen System erlangt hat, das in der Lage ist, die Verwaltungsoberfläche zu erreichen.

Dies macht laterale Bewegung besonders relevant. Eine kompromittierte Workstation, ein Server, ein CI/CD-Runner, ein Verwaltungshost oder eine Cloud-Arbeitslast mit Netzwerkzugang zur LXD-API könnte die Position bieten, die benötigt wird, um ein ansonsten intern exponiertes System auszunutzen.

CVE-2026-112816 Minderung

Canonical empfiehlt, betroffene LXD- und MicroCloud-Implementierungen sofort auf die neuesten behobenen Versionen zu aktualisieren.

Für Snap-basierte Implementierungen können Administratoren mit folgenden Befehlen aktualisieren:

sudo snap refresh lxd

und:

sudo snap refresh microcloud

Nach der Aktualisierung sollte die tatsächlich installierte Version überprüft werden, anstatt anzunehmen, dass das Update erfolgreich angewendet wurde.

Canonical wies während der Offenlegung darauf hin, dass einige LXD-Zwischenversionen von den Kandidaten- zu den stabilen Kanälen fortschritten. Administratoren sollten daher ausdrücklich bestätigen, dass ihr System eine der behobenen Versionen ausführt.

Die primäre CVE-2026-112816-Minderung besteht im Upgrade auf:

Produkt	Behobene Version
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonical hat kein konfigurationsbasiertes Workaround veröffentlicht, das den zugrunde liegenden Authentifikationsfehler vollständig beseitigt.

Wenn ein sofortiges Upgrade nicht möglich ist, beschränken Sie den Netzwerkzugang zur HTTPS-API so aggressiv wie es die Betriebsanforderungen erlauben.

Nur autorisierte Verwaltungshosts und vertrauenswürdige Infrastrukturen sollten in der Lage sein, Verbindungen zum Listener herzustellen.

Für LXD-Installationen, die keine Remote-Verwaltung erfordern, sollten Administratoren prüfen, ob die Netzwerk-API überhaupt aktiviert bleiben muss.

Für Umgebungen, die Remote-Zugriff erfordern:

• Beschränken Sie die API mit Host- oder Netzwerk-Firewalls.
• Erlauben Sie Verbindungen nur von dedizierten Verwaltungsnetzwerken.
• Vermeiden Sie es, die API direkt dem öffentlichen Internet auszusetzen.
• Verwenden Sie, wo angemessen, VPN- oder bastionbasierte administrative Zugänge.
• Segmentieren Sie Container- und Virtualisierungs-Management-Infrastruktur von Benutzernetzwerken.
• Überwachen Sie alle erfolgreichen administrativen API-Anfragen.
• Überprüfen Sie vertrauenswürdige Zertifikate und entfernen Sie Einträge, die nicht mehr notwendig sind.

Diese Kontrollen reduzieren die Exposition, beheben jedoch nicht die anfällige Zertifikat-Validierungslogik.

Unternehmen, die MicroCloud betreiben, sollten die Aktualisierung aller relevanten Cluster-Mitglieder priorisieren und die kürzliche Beitrittsaktivität auf unerwartete Systeme oder Zertifikatsidentitäten überprüfen.

Administratoren sollten auch ihre vertrauenswürdigen Zertifikatspeicher überprüfen.

Entfernen Sie Zertifikate, die zu abgelegten Hosts, ehemaligen Administratoren, ungenutzten Automatisierungssystemen oder Identitäten gehören, die keinen Zugriff mehr benötigen.

Wo verdächtige Aktivitäten entdeckt werden, untersuchen Sie den betroffenen Host und den Cluster, bevor Sie Anmeldedaten drehen oder Beweise modifizieren.

Relevante Telemetriequellen können einschließen:

• LXD- und MicroCloud-Servicelogs
• Linux-Systemprotokolle
• Firewall- und Netzwerkflussprotokolle
• Reverse-Proxy-Telemetrie, falls zutreffend
• Host-EDR-Daten
• Cloud-Netzwerkprotokolle
• Cluster-Konfigurations- und Mitgliedschaftshistorie
• Administrative Änderungsprotokolle

Suchen Sie nach unerwarteten Instanzerstellungen, -änderungen, -löschungen, Snapshot-Aktivitäten, Speicheroperationen, Netzwerkänderungen und Konfigurationsaktualisierungen.

Wenn eine Ausbeutung vermutet wird und eine privilegierte Zertifikatsidentität verkörpert wurde, sollten Verteidiger einen potenziellen Hostebene-Kompromiss ernst nehmen, da Canonical bestätigt, dass Root-Zugriff je nach den Berechtigungen der Opfer-Identität möglich sein kann.

Vorfallreaktionskräfte sollten relevante Beweise bewahren und das System auf Beständigkeit, unautorisierte Konten oder Zertifikate, modifizierte Dienste, neue Arbeitslasten, verdächtige Prozesse und anomale ausgehende Netzwerkkkommunikation untersuchen.

Organisationen, die Incus anstelle von Canonical LXD verwenden, sollten separat auf Incus 7.6.0 oder die betreffende unterstützte behobene Version aktualisieren, da das verwandte Projekt vom gleichen zugrunde liegenden Problem bei der Zertifikatskettenerkennung betroffen war.

Ubuntu stellt außerdem fest, dass seine archivieren-verpackten LXD-Versionen für derzeit gelistete Ubuntu-Releases entweder nicht über den betroffenen Paketpfad vertrieben werden oder nicht betroffen sind, während sich die Sicherheitsrichtlinien von Canonical auf die Snap-Veröffentlichungen konzentrieren. Administratoren sollten dennoch die tatsächliche LXD-Verteilung und Version überprüfen, die in ihrer Umgebung läuft, anstatt sich auf die Exposition ausschließlich basierend auf der Ubuntu-Version zu verlassen.

Haftungsausschluss: Erkennungsinhalte sind möglicherweise nicht für jedes CVE verfügbar. Überprüfen Sie die SOC Prime Platform für aktuelle Abdeckung. Wenn relevante Erkennungen noch nicht verfügbar sind, überprüfen Sie erneut, da laufend neue Bedrohungsinformationen und Erkennungsinhalte hinzugefügt werden.