In dieser Ausgabe geht es um eine einzige Lücke, allerdings um eine schwerwiegende: In Canonical LXD und MicroCloud kann sich ein Angreifer als vertrauenswürdiger Client anmelden, ohne den zugehörigen Private Key zu besitzen. Die Lücke erreicht den Höchstwert von 10,0, Patches sind verfügbar, eine Ausnutzung ist bislang nicht gemeldet.
LXD und MicroCloud: Angreifer meldet sich ohne Private Key als vertrauenswürdiger Client an
| Schwachstelle | Umgehung der Authentifizierung durch fehlerhafte Prüfung von Client-Zertifikatsketten im HTTPS-Listener von Canonical LXD (verwundbar bis einschließlich 4.0.14, 5.0.10, 5.21.8 und 6.9) und MicroCloud. Der Incus-Fork weist dasselbe Problem auf |
| CVE-Nummer | CVE-2026-112816 |
| CVSS-Score | 10,0 |
| Aktiv ausgenutzt | Nein. Laut einer CISA-Bewertung im CVE-Eintrag vom 30. Oktober ist keine Ausnutzung bekannt, die Lücke steht nicht im KEV-Katalog und es gibt keinen öffentlichen Exploit |
| Patch verfügbar | Ja. LXD 6.10.1, 5.21.9, 5.0.11 und 4.0.15, MicroCloud 3.4.1 und 2.1.5, Incus 7.6.0. Einen Workaround gibt es nicht, beschränken Sie bis dahin den Netzwerkzugriff auf die API |
Wie kann die Schwachstelle ausgenutzt werden?
LXD und MicroCloud nutzen gegenseitiges TLS: Ein Client legt ein Zertifikat vor, und der Server vertraut ihm, wenn das Zertifikat im Trust Store hinterlegt ist. Laut dem Advisory von Canonical glich der Server sämtliche vom Client übermittelten Zertifikate mit diesem Store ab, obwohl nur das erste Zertifikat der Kette belegt, dass der Client den zugehörigen Schlüssel besitzt. Ein Angreifer hängt das öffentliche Zertifikat eines vertrauenswürdigen Clients hinter ein eigenes Zertifikat und wird als dieser Client akzeptiert. Dieses öffentliche Zertifikat ist nicht geheim. Bei MicroCloud liegt der Schwachpunkt beim Beitritt zu einem Cluster: Wer das Zertifikat eines beitretenden Mitglieds abfängt, kann sich als dieses Mitglied anmelden. Gemeldet wurde die Lücke vom Incus-Projekt, wie The Hacker News berichtet.
Welche Folgen kann das haben?
Der Angreifer agiert als der imitierte Client, mit Zugriff auf den Cluster und die virtuellen Maschinen. Bei einem privilegierten Client kann das laut Canonical Root-Zugriff auf den Host bedeuten. Voraussetzung ist Netzwerkzugriff auf die HTTPS-API. Eine eigenständige LXD-Installation lauscht standardmäßig nur auf einem lokalen Socket, sofern ein Administrator die Netzwerk-API nicht mit core.https_address aktiviert hat. Am stärksten gefährdet sind daher Cluster, MicroCloud-Umgebungen und Hosts, deren API breit erreichbar ist. Die LXD-Pakete aus dem Ubuntu-Archiv sind nicht betroffen, der Fix steckt in den Snaps.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie LXD und MicroCloud mit sudo snap refresh lxd und sudo snap refresh microcloud und prüfen Sie anschließend die installierte Version. Canonical zufolge wurden die LXD-Releases noch vom Candidate- in den Stable-Kanal ausgerollt, ein Refresh auf dem Stable-Kanal liefert also möglicherweise nicht sofort die gepatchte Version. Ermitteln Sie, welche Hosts die API über das Netzwerk bereitstellen, und schotten Sie diese gegen alles außerhalb Ihres Verwaltungsnetzes ab, bis der Patch installiert ist. Wenn Sie Incus einsetzen, wechseln Sie auf Version 7.6.0.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
