LXD certificate flaw ermöglicht das Auftreten als vertrauenswürdiger Client
Eine kritische LXD certificate flaw ermöglicht es einem Angreifer, als vertrauenswürdiger Client aufzutreten, ohne den private key dieses Clients zu besitzen – also das Geheimnis, mit dem dessen Identität nachgewiesen wird. Das Problem betrifft die Canonical-Produkte LXD und MicroCloud und könnte einen Cluster sowie dessen virtual machines offenlegen, also softwarebasierte Computer, die innerhalb eines physischen Hosts ausgeführt werden. Canonical warnte, dass das Auftreten als privilegiertes Konto dem Angreifer root access und damit die vollständige administrative Kontrolle über die Host-Maschine verschaffen könnte.
Die Schwachstelle wird als CVE-2026-112816 geführt und hat mit 10,0 den maximalen CVSS-Wert. CVSS, das Common Vulnerability Scoring System, ist eine Standardskala zur Bewertung des Schweregrads von Sicherheitslücken. Canonical hat korrigierte Versionen von LXD und MicroCloud veröffentlicht. Administratoren müssen jedoch überprüfen, ob ihre installierte Version das Update tatsächlich erhalten hat.
LXD und MicroCloud ermöglichen Remote-Clients die Verbindung über eine HTTPS API, eine verschlüsselte Netzwerkschnittstelle, über die Software Anweisungen und Daten austauscht. Die Authentifizierung erfolgt über mutual TLS, eine Verbindung, bei der sowohl der Server als auch der sich verbindende Client digitale certificates verwenden, um ihre Identität nachzuweisen. Ein Server betrachtet einen Client als vertrauenswürdig, wenn dessen certificate in seinem trust store erscheint, also in der Liste der Identitäten, die er akzeptieren soll.
Die Schwachstelle betraf die Art und Weise, wie der Server die während einer Verbindung übermittelte certificate chain untersuchte. Der Server verglich jedes vom Client bereitgestellte certificate mit den Einträgen in seinem trust store. Die TLS-Verbindung weist jedoch nur nach, dass der sich verbindende Client den private key besitzt, der zum ersten certificate in dieser chain gehört, dem sogenannten leaf certificate. Alle dahinter angefügten certificates werden vom sich verbindenden Client ausgewählt und sind von diesem Eigentumsnachweis nicht abgedeckt.
Ein Angreifer konnte sich daher mit einem certificate und private key unter seiner Kontrolle verbinden und anschließend das public certificate eines legitimen, vertrauenswürdigen Clients anhängen. Public certificates sind nicht geheim. Da der anfällige Server alle certificates in der übermittelten chain überprüfte, konnte er das vertrauenswürdige certificate finden und den Angreifer als diesen Client akzeptieren, obwohl der Angreifer den private key des vertrauenswürdigen Clients nicht besaß.
Für eine Ausnutzung müssen zwei Bedingungen erfüllt sein. Der Angreifer muss die HTTPS API des Ziels über das Netzwerk erreichen können und das public certificate eines Clients besitzen, dem der Server bereits vertraut. Eine eigenständige LXD-Installation stellt ihre API standardmäßig nicht im Netzwerk bereit. Sie lauscht ausschließlich über einen local socket, eine Verbindung, die auf derselben Maschine verfügbar ist, sofern ein Administrator den Netzwerkzugriff nicht mit der Einstellung core.https_address aktiviert.
MicroCloud weist eine zusätzliche Angriffsfläche auf, da es mehrere LXD-Maschinen zu einem Cluster zusammenfasst. Canonical erklärte, dass ein Angreifer, der das public certificate eines Mitglieds während dessen Beitritt zum Cluster abfängt, sich später als dieses Mitglied authentifizieren könnte. Eine erfolgreiche Identitätsvortäuschung würde dem Angreifer sämtliche Cluster- und virtual-machine-Berechtigungen geben, die dieser Identität zugewiesen wurden.
Der CVE-Eintrag nennt LXD 4.0.14, 5.0.10, 5.21.8 und 6.9 als betroffen, jeweils vor den entsprechenden korrigierten Releases. Canonical führt LXD 6.10.1 im snap channel 6/stable, 5.21.9 in 5.21/stable, 5.0.11 in 5.0/stable und 4.0.15 in 4.0/stable als korrigiert auf. Bei MicroCloud sind die korrigierten Versionen 3.4.1 in 3/stable und 2.1.5 in 2/stable. Ein snap ist das Paketformat, über das diese Releases verteilt werden.
Das Incus-Projekt, das als Community-Fork von LXD begann, meldete ursprünglich das zugrunde liegende Problem. Canonical bestätigte anschließend, dass auch LXD anfällig war. Incus korrigierte dieselbe Schwachstelle in Version 7.6.0 zusammen mit 17 weiteren Sicherheitsproblemen. Die Archive-Pakete von Ubuntu für LXD werden entweder als nicht betroffen oder als nicht ausgeliefert aufgeführt. Bei den relevanten korrigierten LXD-Releases handelt es sich daher um die snap-Pakete.
Es gibt keine öffentlichen Hinweise darauf, dass CVE-2026-112816 ausgenutzt wurde. Laut einer auf den 30. Oktober datierten Bewertung der U.S. Cybersecurity and Infrastructure Security Agency ist nicht bekannt, dass die Schwachstelle bei Angriffen eingesetzt wurde. Sie ist nicht in der Known Exploited Vulnerabilities-Liste der Behörde enthalten, und es wurde kein funktionsfähiger öffentlicher Exploit veröffentlicht.
Administratoren sollten snap-Installationen aktualisieren, indem sie sudo snap refresh lxd und sudo snap refresh microcloud ausführen. Zum Zeitpunkt des Sicherheitshinweises von Canonical wurden die korrigierten LXD point releases noch vom candidate channel in stable übertragen. Administratoren sollten deshalb nach dem Aktualisieren die installierte Version prüfen, statt davon auszugehen, dass das korrigierte Release bereitgestellt wurde.
Canonical stellte keinen vorübergehenden Workaround für LXD bereit. Eine Beschränkung des Zugriffs auf die HTTPS API kann die Angriffsfläche verringern, solange das Update noch aussteht, behebt jedoch nicht den certificate-validation error. Das Incus-Projekt erklärte ebenfalls, dass es keine konfigurationsbasierte Korrektur gebe, und empfahl, den Netzwerkzugriff auf den listener einzuschränken, bis die Systeme aktualisiert werden können. Incus-Benutzer sollten Version 7.6.0 installieren.
Organisationen, die Unterstützung bei der Absicherung der umgebenden IT-Umgebung benötigen, können AEU-I für sicherheitsorientierte IT, Infrastruktur und Beratung nutzen. Für betroffene Installationen bleibt die Installation des korrigierten Releases, die Bestätigung seiner Version und die Abschirmung der Management-API von nicht vertrauenswürdigen Netzwerken die höchste Priorität.