Canonical hat Korrekturen für eine Schwachstelle bei der Zertifikatsprüfung veröffentlicht, mit der Angreifer sich ohne die privaten Schlüssel als vertrauenswürdige LXD- und MicroCloud-Clients ausgeben können, berichtet The Hacker News. Der Ubuntu-Sicherheitshinweis vom 30. Oktober führt die LXD-Lücke als CVE-2026-112816 auf. Sie kann einem nicht authentifizierten Angreifer vollen Zugriff auf einen Cluster und dessen verwaltete virtuelle Maschinen verschaffen.
Für die Ausnutzung ist Netzwerkzugriff auf die HTTPS-API erforderlich – die verschlüsselte Schnittstelle zur Verwaltung des Dienstes – sowie das öffentliche Zertifikat einer Identität, der der Server vertraut. Der Angreifer erhält die Zugriffsrechte dieser Identität. Laut Canonical, wie The Hacker News unter Berufung auf Aussagen des Unternehmens berichtet, könnte die Nachahmung eines privilegierten Kontos außerdem Root-Zugriff auf den Host-Rechner ermöglichen.
Eigenständige LXD-Installationen stellen diese Netzwerkschnittstelle standardmäßig nicht bereit. Sie lauschen auf einem lokalen Socket, es sei denn, ein Administrator aktiviert den Netzwerkzugriff über core.https_address. MicroCloud, das mehrere LXD-Rechner zu einem Cluster zusammenfasst, ist besonders exponiert: Laut Canonical kann ein Angreifer, der das öffentliche Zertifikat eines Mitglieds abfängt, während dieses dem Cluster beitritt, sich anschließend als dieses Mitglied ausgeben.
Die Schwachstelle erhält im Common Vulnerability Scoring System die maximale Schweregradbewertung 10,0, während Ubuntu ihr eine eigene Behebungspriorität „Medium“ zuweist. The Hacker News berichtet, dass in einer CISA-Bewertung vom 30. Oktober im CVE-Eintrag eine Ausnutzung als nicht bekannt beschrieben wurde. Die Lücke fehlte im Katalog bekannter ausgenutzter Schwachstellen (Known Exploited Vulnerabilities) der CISA, und es war kein funktionierender Exploit veröffentlicht worden.
Wie aus einem öffentlichen Zertifikat eine Anmeldung wird
LXD und MicroCloud unterstützen gegenseitiges TLS, einen Verbindungsaufbau, bei dem Clients Zertifikate vorlegen, um ihre Identität nachzuweisen. Server speichern akzeptierte Identitäten in einem Trust Store. Ein öffentliches Zertifikat ist nicht geheim. Sein zugehöriger privater Schlüssel soll belegen, dass der Client die Identität besitzt.
Die Lücke hebt diese Unterscheidung auf. Beim Verbindungsaufbau weist TLS den Besitz des privaten Schlüssels nur für das erste vorgelegte Zertifikat nach, das sogenannte Leaf-Zertifikat. Die anfällige Authentifizierung glich dennoch jedes Zertifikat in der Kette des Clients mit dem Trust Store ab, einschließlich zusätzlicher Zertifikate, die der Client frei anhängen konnte.
Ein Angreifer könnte daher zuerst sein eigenes Zertifikat vorlegen und das öffentliche Zertifikat eines vertrauten Clients anhängen. Der Server würde die vertraute Identität akzeptieren, obwohl dem Angreifer deren privater Schlüssel fehlt.
Das Incus-Projekt, ein Community-Fork von LXD, hat das Problem gemeldet. Canonical bestätigte laut The Hacker News, dass auch LXD betroffen war. Incus veröffentlichte am 29. Oktober, einen Tag vor der Mitteilung von Ubuntu, einen eigenen Sicherheitshinweis. Laut dem Hinweis besteht das Verhalten seit der ersten Veröffentlichung von Incus und betrifft Versionen vor 7.6.0.
Incus beschreibt weitere Zugriffswege
Der Incus-Hinweis beschreibt Folgen innerhalb dieses Produkts, die über die Nachahmung eines gewöhnlichen Clients hinausgehen. Wer den HTTPS-Listener erreichen kann, kann einen vertrauten Client, eine Metrics-Identität oder ein Serverzertifikat imitieren, dessen öffentliches Zertifikat er besitzt. Die Nachahmung eines Cluster-Mitglieds umgeht die Autorisierung vollständig.
Ein geeignetes öffentliches Zertifikat zu beschaffen, erfordert in Incus möglicherweise keinen vorherigen Zugriff, denn Server übermitteln ihre Zertifikate bei jedem TLS-Handshake. Das Anhängen des Zertifikats des Zielservers selbst gewährt Zugriff auf das Datenbank-Gateway. Das Anhängen des Zertifikats eines anderen Cluster-Mitglieds gewährt internen Cluster-Zugriff. Vertraute Clients können außerdem Client-Zertifikate über die Certificates-API abrufen, und Zertifikate lassen sich von Servern beziehen, die diese Clients kontaktiert haben.
Incus zufolge erlaubt die Lücke außerdem das Erneuern oder Löschen beliebiger Trust-Store-Einträge über Self-Service-Pfade. Sie betrifft zudem die Authentifizierung der Agent-Verbindung zwischen Hosts und virtuellen Maschinen.
Eine weitere Folge betrifft das Autorisierungs-Scriptlet, ein Skript für Zugriffsentscheidungen. Incus übergab die ungeprüfte Zertifikatskette an dieses Skript, sodass vom Angreifer gewählte Zertifikate dessen Entscheidungen beeinflussen konnten. Betroffen sind auch Clients, die sich über Tokens oder OpenID Connect authentifizieren, eine identitätsbasierte Anmeldemethode. Sie können beim TLS-Verbindungsaufbau weiterhin beliebige Zertifikate vorlegen.
Diese detaillierten Auswirkungen stammen aus dem Incus-Hinweis. Dort wird das Problem als GHSA-xg75-xf37-cph9 geführt. Eine bekannte CVE-Kennung wird nicht genannt.
Korrigierte Versionen und Schritte für Administratoren
Der Ubuntu-Hinweis führt LXD 4.0.14, 5.0.10, 5.21.8 und 6.9 als betroffen auf, jeweils vor den entsprechenden korrigierten Versionen. The Hacker News berichtet über diese korrigierten Snap-Versionen, nach Produkt und Kanal gruppiert:
- LXD
6/stable: 6.10.1. - LXD
5.21/stable: 5.21.9. - LXD
5.0/stable: 5.0.11. - LXD
4.0/stable: 4.0.15. - MicroCloud
3/stable: 3.4.1. - MicroCloud
2/stable: 2.1.5.
Der Paketstatus im Ubuntu-Archiv ist von diesen Snap-Installationen getrennt zu betrachten. Die LXD-Pakete für Ubuntu 20.04, 18.04 und 16.04 sind als nicht betroffen markiert. Für die Versionen 22.04, 24.04, 26.04 und 26.10 ist LXD als nicht enthalten aufgeführt.
Administratoren, die Snaps verwenden, sollten die installierten Produkte mit sudo snap refresh lxd und sudo snap refresh microcloud aktualisieren. Canonical erklärte, dass die korrigierten LXD-Point-Releases zum Zeitpunkt der Veröffentlichung des Hinweises noch vom Candidate-Kanal in den Stable-Kanal wanderten. Administratoren sollten deshalb nach dem Aktualisieren die installierte Version prüfen.
The Hacker News berichtet, dass der Hinweis von Canonical keine temporäre Umgehungslösung für LXD nennt. Die Beschränkung des Netzwerkzugriffs auf die HTTPS-API verringert die Exposition, während Updates eingespielt werden. Incus empfiehlt ausdrücklich, den HTTPS-Listener auf vertrauenswürdige Hosts zu beschränken, und erklärt, dass es keine konfigurationsbasierte Umgehungslösung gibt. Incus-Administratoren sollten auf 7.6.0 aktualisieren. Diese Version behebt die Lücke zusammen mit 17 weiteren Sicherheitsproblemen.
