Kritische Schwachstelle in LXD und MicroCloud ermöglicht Root-Zugriff ohne private Schlüssel

Canonical hat Notfall-Patches für eine kritische Sicherheitslücke in seinem Container-Hypervisor LXD und dem Clustering-Tool MicroCloud veröffentlicht. Die Schwachstelle, die unter der Kennung CVE-2026-112816 geführt wird, weist im Common Vulnerability Scoring System (CVSS) die maximale Schweregradbewertung von 10.0 auf. Sie ermöglicht es Remote-Angreifern, sich als vertrauenswürdige Clients auszugeben und unbefugten Zugriff auf die Infrastruktur zu erhalten, ohne über die erforderlichen privaten kryptografischen Schlüssel zu verfügen.

Was ist passiert?

Die Schwachstelle ermöglicht es einem Angreifer, sich als vertrauenswürdiger Client anzumelden, indem er einen Verifizierungsfehler im Prozess der gegenseitigen TLS-Authentifizierung (mutual TLS) ausnutzt. Um erfolgreich zu sein, benötigt der Angreifer Netzwerkzugriff auf die HTTPS-API sowie das öffentliche Zertifikat eines Clients, dem der Server bereits vertraut. Nach der Authentifizierung agiert der Angreifer als dieser Client und erhält vollen Zugriff auf den Cluster und dessen virtuelle Maschinen. Wenn das impersonierte Konto privilegierte Rechte besitzt, kann der Angreifer auf Root-Rechte auf der Host-Maschine selbst eskalieren.

Dieses Problem wurde ursprünglich vom Incus-Projekt gemeldet, einer Community-Fork von LXD, die bestätigte, dass der Bug beide Plattformen betrifft. Während die Standard-Archivpakete von Ubuntu für LXD nicht betroffen sind, sind Nutzer, die LXD oder MicroCloud über Snap-Pakete betreiben, gefährdet. Canonical hat erklärt, dass es keine Hinweise darauf gibt, dass diese Schwachstelle in freier Wildbahn ausgenutzt wurde, und sie erscheint derzeit nicht auf der Liste der bekannten ausgenutzten Schwachstellen der CISA (Known Exploited Vulnerabilities). Das potenzielle Ausmaß ist jedoch schwerwiegend genug, um sofortige Aufmerksamkeit seitens der Infrastruktur-Teams zu erfordern.

Wie funktioniert es?

LXD und MicroCloud nutzen gegenseitiges TLS (mTLS), um den Fernzugriff auf die API abzusichern. In diesem Setup beweist ein Client seine Identität durch die Vorlage eines digitalen Zertifikats. Der Server prüft dieses Zertifikat gegen einen Trust Store, der die Identitäten aller zulässigen Clients enthält. Die Schwachstelle liegt darin, wie der Server die Zertifikatskette während des Handshakes validiert.

Bei einer standardmäßigen TLS-Verbindung beweist das Protokoll kryptografisch nur, dass der Client den privaten Schlüssel für das erste Zertifikat in der Kette besitzt, das sogenannte Leaf-Zertifikat. Der Rest der Kette ist lediglich Daten, die vom Client angehängt werden. Die fehlerhafte Implementierung in LXD verglich jedes Zertifikat in der bereitgestellten Kette mit dem Trust Store, anstatt streng nur das Leaf-Zertifikat zu validieren. Ein Angreifer konnte das öffentliche Zertifikat eines vertrauenswürdigen Clients nehmen – welches nicht geheim ist – und es seiner eigenen Kette hinzufügen. Der Server hätte dann fälschlicherweise den Angreifer als vertrauenswürdigen Client akzeptiert, weil er einen Treffer in der Kette fand, obwohl der Angreifer nicht den entsprechenden privaten Schlüssel für dieses spezifische Zertifikat besaß.

Wichtige Details

• Schwachstellen-ID: CVE-2026-112816 mit einem CVSS-Score von 10.0.
• Betroffene Produkte: LXD-Versionen 4.0.14, 5.0.10, 5.21.8 und 6.9 sowie MicroCloud-Cluster.
• Behobene Versionen: LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15 und MicroCloud 3.4.1 oder 2.1.5 über Snap-Kanäle.
• Anforderungen für den Angriff: Netzwerkzugriff auf die HTTPS-API und Besitz des öffentlichen Zertifikats eines vertrauenswürdigen Clients.
• Ursprung: Gemeldet vom Incus-Projekt, das seinen eigenen Fix in Version 7.6.0 veröffentlichte.
• Exploit-Status: Stand 30. Oktober 2026 gibt es keine bekannte aktive Ausnutzung oder öffentlichen Exploit-Code.

Warum ist das wichtig?

Für Ingenieure, die containerisierte Infrastrukturen verwalten, untergräbt diese Schwachstelle das grundlegende Vertrauensmodell von mTLS. Mutual TLS wird oft als starker Authentifizierungsmechanismus angesehen, da er den Besitz eines privaten Schlüssels erfordert. Dieser Fehler umgeht diese Anforderung vollständig, was bedeutet, dass allein der Besitz eines öffentlichen Zertifikats – das oft offen verteilt oder bei Netzwerkbeitritten abgefangen wird – für eine Impersonation ausreicht. Dies ist besonders gefährlich für MicroCloud-Umgebungen, in denen ein Angreifer, der das öffentliche Zertifikat eines Mitglieds während des Beitritts zum Cluster abfängt, dieses Mitglied anschließend impersonieren kann.

Die Auswirkungen gehen über einfachen Datenzugriff hinaus. Da LXD systemnahe Container verwaltet, kann eine erfolgreiche Impersonation eines privilegierten Clients zur vollständigen Kompromittierung des Hosts führen. Dies gewährt dem Angreifer Root-Zugriff auf die zugrunde liegende physische oder virtuelle Maschine und ermöglicht ihm, die Container-Umgebung vollständig zu verlassen. Für Teams, die LXD in Produktion einsetzen, insbesondere solche, die die API über ein Netzwerk exponieren, stellt dies ein kritisches Versagen der Zugriffskontrolle dar, das nicht allein durch Konfigurationsänderungen entschärft werden kann.

Was Sie tun können

• Aktualisieren Sie Ihre LXD- und MicroCloud-Installationen sofort mit sudo snap refresh lxd und sudo snap refresh microcloud.
• Überprüfen Sie die installierte Version nach dem Update, da Fixes schrittweise von Candidate- zu Stable-Kanälen ausgerollt werden können.
• Schränken Sie den Netzwerkzugriff auf den LXD-API-Listener ein, wenn Sie nicht sofort aktualisieren können, da der Angriff direkten HTTPS-API-Zugriff erfordert.
• Prüfen Sie, ob Ihr eigenständiger LXD-Server core.https_address aktiviert hat; wenn nicht, ist er wahrscheinlich nicht diesem spezifischen Remote-Angriffsvektor ausgesetzt.
• Überwachen Sie ungewöhnliche Aktivitäten in der Cluster-Mitgliedschaft oder den API-Logs, die auf versuchte Impersonationen hindeuten könnten.
• Wenn Sie Incus anstelle von LXD verwenden, aktualisieren Sie auf Version 7.6.0 oder höher, um dieses und 17 weitere Sicherheitsprobleme zu beheben.