CVE-2026-112816: Krytyczna luka w uwierzytelnianiu LXD i MicroCloud umożliwia przejęcie klastra

Canonical opublikował poprawki bezpieczeństwa dotyczące CVE-2026-112816, krytycznej luki umożliwiającej ominięcie uwierzytelnienia, wpływającej na LXD i MicroCloud. Luka otrzymała maksymalną ocenę CVSS wynoszącą 10,0 i może pozwolić niezalogowanemu atakującemu zdalnie podszywać się pod zaufanego klienta TLS bez posiadania klucza prywatnego tego klienta.

Pomyślne wykorzystanie tej luki może zapewnić dostęp do LXD lub MicroCloud API z uprawnieniami przypisanymi do podszywanej tożsamości. Gdy zaufana tożsamość ma wystarczające uprawnienia, atakujący może uzyskać pełny dostęp do klastra, zarządzanych maszyn wirtualnych, a potencjalnie również do poziomu root hosta bazowego.

Wada wynika z niewłaściwej weryfikacji łańcuchów certyfikatów klienta używanych do wzajemnego uwierzytelniania TLS. Zamiast uwierzytelniać wyłącznie końcowy certyfikat, dla którego klient potwierdza posiadanie odpowiadającego mu klucza prywatnego, podatne implementacje porównują każdy certyfikat dostarczony w łańcuchu kontrolowanym przez klienta z zaufanymi certyfikatami.

Atakujący, który może dotrzeć do HTTPS API i uzyskać publiczny certyfikat już zaufanego klienta, może zatem dołączyć ten certyfikat za certyfikatem końcowym kontrolowanym przez atakującego i zostać zaakceptowany jako zaufana tożsamość.

Canonical ujawnił ten problem pod koniec października 2026 roku po skierowaniu zgłoszenia przez projekt Incus. Teraz dostępne są poprawione wersje LXD i MicroCloud i administratorzy są zdecydowanie zalecani do natychmiastowej aktualizacji.

Luka ma szczególne znaczenie w środowiskach infrastruktury, ponieważ LXD zarządza kontenerami systemowymi i maszynami wirtualnymi, a MicroCloud koordynuje skupioną infrastrukturę. Kompromitacja tożsamości administracyjnej może więc wykraczać poza pojedynczą usługę i zapewniać kontrolę nad obciążeniami roboczymi lub samym hostem.

W celu wykrycia CVE-2026-112816 zespoły bezpieczeństwa powinny w pierwszej kolejności zidentyfikować dostępne przez internet lub sieć interfejsy LXD i MicroCloud HTTPS API, przejrzeć zaufane certyfikaty klientów oraz skorelować udane uwierzytelnienia oparte na certyfikatach ze źródłowymi systemami lub nietypowymi operacjami administracyjnymi.

Platforma SOC Prime AI-Native Detection Intelligence umożliwia zespołom bezpieczeństwa wzmocnienie zasięgu dla eksploatacji i zachowań po kompromitacji w zakresie telemetrii sieci, Linuksa, chmury, kontenerów i tożsamości.

Skontaktuj się z działem sprzedaży

Kliknij Eksploruj wykrycia, aby uzyskać dostęp do odpowiednich treści związanych z wykrywaniem i logiką polowania. Aby wykryć CVE-2026-112816, obrońcy powinni połączyć inwentarz podatnych wersji z monitorowaniem dostępu do API, telemetrią uwierzytelnienia certyfikatu oraz podejrzanymi działaniami administracyjnymi wpływającymi na kontenery, maszyny wirtualne lub konfigurację klastra.

Analiza CVE-2026-112816

CVE-2026-112816 to luka polegająca na niewłaściwej walidacji certyfikatu w nasłuchiwaczu HTTPS używanym przez LXD i MicroCloud Canonical.

Oba produkty mogą korzystać z wzajemnego TLS do uwierzytelniania zdalnych klientów. Pod normalnym zachowaniem mTLS, łączący się klient przedstawia certyfikat i potwierdza własność klucza prywatnego powiązanego z certyfikatem używanym jako końcowy w łańcuchu TLS.

Problem powstaje, ponieważ podatne implementacje LXD i MicroCloud badają więcej niż ten uwierzytelniony końcowy certyfikat.

Zgodnie z informacjami Canonical, logika uwierzytelniania zdalnego API porównywała wszystkie certyfikaty przedstawiane przez klienta z wpisami w zaufanym sklepie certyfikatów. Jednak TLS potwierdza posiadanie klucza prywatnego wyłącznie dla certyfikatu końcowego. Dodatkowe certyfikaty w przedstawionym łańcuchu są dostarczane przez klienta i nie dowodzą niezależnie posiadania odpowiadających im kluczy prywatnych.

To tworzy lukę w uwierzytelnianiu.

Atakujący może wygenerować certyfikat i klucz prywatny, którym zarządza, użyć tego certyfikatu jako końcowego i dołączyć publiczny certyfikat zaufanego klienta gdzie indziej w przedstawionym łańcuchu. Zdalna strona serwera może znaleźć zaufany certyfikat i połączyć połączenie z tą zaufaną tożsamością, mimo że atakujący nie posiada jej klucza prywatnego.

Szczegóły dotyczące CVE-2026-112816 pokazują zatem, że eksploatacja zależy głównie od dwóch przesłanek:

• Atakujący może dotrzeć do LXD lub MicroCloud HTTPS API.
• Atakujący posiada publiczny certyfikat tożsamości już zaufanej przez cel.

Klucz prywatny zaufanego klienta nie jest wymagany.

To rozróżnienie wyjaśnia krytyczną wagę luki. Uwierzytelnienie oparte na certyfikatach ma demonstrować posiadanie tajnego klucza prywatnego, ale dotknięta logika skutecznie pozwala na posiadanie samego publicznego certyfikatu, aby zaspokoić część decyzji dotyczącej zaufania.

Samodzielna instalacja LXD domyślnie nie wystawia swojego zdalnego HTTPS API. Według The Hacker News, LXD normalnie nasłuchuje tylko na swoim lokalnym gnieździe Unix, chyba że administrator włączy dostęp sieciowy, na przykład za pośrednictwem konfiguracji core.https_address.

To oznacza, że nie każda podatna instalacja LXD jest możliwa do zdalnego wyeksploatowania z innego hosta.

Narażenie staje się znacznie większe, gdy administratorzy włączają API w całej sieci zarządzania lub wystawiają je do internetu.

MicroCloud przedstawia kolejny istotny scenariusz ataku. Canonical stwierdza, że atakujący, który może przechwycić publiczny certyfikat TLS maszyny dołączającej do klastra MicroCloud, może następnie uwierzytelnić się jako ten dołączony członek.

CVE-2026-112816 wpływa na podatne wersje LXD Canonical, w tym 4.0.14, 5.0.10, 5.21.8, i 6.9 przed ich odpowiednimi poprawkami.

Canonical wymienia te załatane wersje LXD:

• LXD 6.10.1 dla kanału 6/stable
• LXD 5.21.9 dla 5.21/stable
• LXD 5.0.11 dla 5.0/stable
• LXD 4.0.15 dla 4.0/stable

Dla MicroCloud, poprawione wersje to:

• MicroCloud 3.4.1 dla 3/stable
• MicroCloud 2.1.5 dla 2/stable

Rekord CVE Ubuntu opisuje pomyślne wykorzystanie jako umożliwienie niezalogowanemu atakującemu uwierzytelnienia się jako zaufany klient i uzyskanie pełnego dostępu do klastra oraz zarządzanych maszyn wirtualnych poprzez sfałszowany łańcuch certyfikatów.

Maksymalna ocena CVSS 10,0 odzwierciedla dostępność w sieci, niską złożoność ataku, brak wymaganych uprawnień i brak interakcji użytkownika, łącznie z potencjalnie wysokim wpływem na poufność, integralność i dostępność.

Ostateczny wpływ zależy od uprawnień tożsamości, która jest podszywana.

Ograniczona tożsamość może zapewniać ograniczone możliwości API. Tożsamość klienta lub klastra o wysokich uprawnieniach może zapewniać znacznie większy dostęp.

Canonical wyraźnie ostrzega, że podszycie się pod zaufanego użytkownika o wysokich uprawnieniach może doprowadzić do uzyskania dostępu root do maszyny głównej.

To może potencjalnie pozwolić atakującemu na:

• Zarządzanie lub modyfikację kontenerów i maszyn wirtualnych.
• Dostęp do obciążeń zarządzanych przez podatne środowisko LXD.
• Modyfikację konfiguracji infrastruktury.
• Tworzenie nowych obciążeń lub zmiany w istniejących.
• Zakłócanie dostępności.
• Dostęp do danych dostępnych dla podszywanej tożsamości.
• Potencjalnie osiągnięcie poziomu root hosta, gdy dostępne są wystarczające uprawnienia.

Ta luka została pierwotnie zidentyfikowana w powiązanym projekcie Incus, a następnie skierowana do Canonical, który potwierdził, że ten sam problem uwierzytelniania łańcucha certyfikatów dotyczy LXD.

Incus opisuje podstawowy problem podobnie: serwer żądał certyfikatów klienta bez weryfikacji całego zgłoszonego łańcucha, a kontrole zaufania przechodziły każdą dostarczoną równorzędną strukturę certyfikatu, a nie ograniczały uwierzytelniania do faktycznego certyfikatu końcowego. Incus rozwiązał problem w wersji 7.6.0.

Wydaje się, że luka istniała przez długi okres. Incus twierdzi, że równoważna logika uwierzytelniania była obecna od momentu pierwszego wydania. Publiczne ogłoszenie Canonical nie dostarcza dokładnej daty, kiedy zachowanie podatne w LXD zostało wprowadzone.

Na dzień 2 listopada 2026 roku, niezależny PoC CVE-2026-112816 i reprodukcja laboratoryjna zostały opublikowane publicznie. To stanowi zmianę od raportu The Hacker News opublikowanego 1 listopada, który stwierdzał, że żadne działające exploit nie zostały jeszcze wydane. Publiczna reprodukcja pojawiła się po ujawnieniu i nie jest oryginalnym badaniem dotyczącym podatności.

Canonical oraz powiązane raporty nie wskazały, że luka była wykorzystywana w prawdziwych atakach.

Jak wynika z raportu The Hacker News, problem nie był znany jako wykorzystywany w czasie oceny CISA USA z dnia 30 października i nie został uwzględniony w katalogu znanych wykorzystywanych podatności CISA w tym czasie.

W związku z tym nie ma konkretnych CVE-2026-112816 IOCs, takich jak potwierdzone złośliwe adresy IP, domeny, hashe malware, czy znana infrastruktura atakująca związana z eksploatacją.

Obrońcy powinni zamiast tego skupić się na narażeniu na podatność i zachowaniach.

Potencjalne możliwości polowania obejmują:

• Zdalne połączenia do LXD lub MicroCloud HTTPS API z nieoczekiwanych systemów.
• Udane uwierzytelnienia API pochodzące z sieci, których zaufani administratorzy zwykle nie używają.
• Zaufana tożsamość certyfikatu pojawiająca się z wielu niepowiązanych systemów źródłowych.
• Działalność administracyjna API, która nie pasuje do oczekiwanego właściciela certyfikatu.
• Nieoczekiwane tworzenie, usuwanie lub modyfikacja kontenerów i maszyn wirtualnych.
• Zmiany w wpisach zaufanych certyfikatów.
• Nowi lub zmienieni członkowie klastra.
• Nieoczekiwane zmiany w zakresie przechowywania, sieci, profili, projektów lub konfiguracji instancji.
• Uprawnione operacje występujące krótko po nietypowym uwierzytelnieniu opartej na certyfikacie.
• Połączenia API z interfejsami zarządzania, które nie były przeznaczone do zdalnego dostępu.

Organizacje powinny również zinwentaryzować zaufane certyfikaty powiązane z byłymi administratorami, wycofani hostami, systemami automatyzacji i członkami klastra.

Ponieważ eksploatacja wymaga publicznego certyfikatu zamiast klucza prywatnego, obrońcy nie powinni traktować poufności kluczy prywatnych jako wystarczającej ochrony przed tą konkretną podatnością.

Monitorowanie powinno również uwzględniać współdzielone sieci zarządzania.

API, które nie jest bezpośrednio wystawione na publiczny internet, może wciąż być podatne na atakującego, który już uzyskał punkt zaczepienia na innym systemie zdolnym do dotarcia do interfejsu zarządzania.

To sprawia, że ruch boczny jest szczególnie istotny. Kompromitowana stacja robocza, serwer, runner CI/CD, host zarządzania lub obciążenie chmurowe z dostępem sieciowym do LXD API może zapewnić pozycję potrzebną do eksploatacji systemu narażonego wewnętrznie.

Mitigacja CVE-2026-112816

Canonical zaleca natychmiastową aktualizację dotkniętych instalacji LXD i MicroCloud do najnowszych poprawek.

Dla instalacji opartych na Snap, administratorzy mogą zaktualizować za pomocą komendy:

sudo snap refresh lxd

oraz:

sudo snap refresh microcloud

Po odświeżeniu, zweryfikuj faktycznie zainstalowaną wersję zamiast zakładać, że aktualizacja zakończyła się pomyślnie.

Canonical zauważył podczas ujawnienia, że niektóre wydania punktowe LXD przechodziły z kanałów kandydujących do stabilnych. Administratorzy powinni zatem wyraźnie potwierdzić, że ich system działa na jednej z załatanych wersji.

Główna mitigacja CVE-2026-112816 polega na aktualizacji do:

Produkt	Załatana wersja
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 nie opublikował konfiguracji obejścia, które całkowicie eliminuje podstawowy defekt uwierzytelniania.

Jeśli natychmiastowa aktualizacja jest niemożliwa, ogranicz dostęp sieciowy do HTTPS API tak rygorystycznie, jak to tylko możliwe, uwzględniając wymagania operacyjne.

Tylko uprawnione hosty zarządzania i zaufana infrastruktura powinny móc nawiązywać połączenia z nasłuchiwaczem.

W przypadku instalacji LXD, które nie wymagają zdalnego zarządzania, administratorzy powinni ocenić, czy sieć API w ogóle musi pozostać włączona.

Dla środowisk, które wymagają zdalnego dostępu:

• Ogranicz API za pomocą zapór sieciowych hosta lub sieciowych.
• Zezwalaj na połączenia tylko z dedykowanych sieci zarządzania.
• Unikaj bezpośredniego wystawiania API na publiczny internet.
• W razie potrzeby używaj dostępu administracyjnego opartego na VPN lub bastionie.
• Segmentuj infrastrukturę zarządzania kontenerami i wirtualizacją od sieci użytkowników.
• Monitoruj wszystkie udane żądania administracyjne API.
• Przejrzyj zaufane certyfikaty i usuń wpisy, które nie są już potrzebne.

Te kontrole zmniejszają narażenie, ale nie naprawiają źle działającą logikę walidacji certyfikatów.

Organizacje prowadzące MicroCloud powinny w pierwszej kolejności zaktualizować wszystkich członków klastra i przejrzeć ostatnią aktywność związana z dołączaniem pod kątem nieoczekiwanych systemów lub tożsamości certyfikatów.

Administratorzy powinni również przeglądać swoje zaufane zgromadzenia certyfikatów.

Usuń certyfikaty należące do wycofanych hostów, byłych administratorów, nieużywanych systemów automatyzacji lub tożsamości, które nie wymagają już dostępu.

W przypadku odkrycia podejrzanej aktywności, zbadaj zaatakowany host i klaster przed rotacją poświadczeń lub modyfikacją dowodów.

Ważne źródła telemetrii mogą obejmować:

• Logi serwisowe LXD i MicroCloud
• Logi systemów Linux
• Rekordy zapór sieciowych i przepływów sieciowych
• Telemetria odwrotnego proxy, jeśli dotyczy
• Dane EDR hosta
• Logi sieci chmury
• Historia konfiguracji i członkostwa klastra
• Rekordy zmian administracyjnych

Poszukaj nieoczekiwanego tworzenia, modyfikacji, usuwania instancji, aktywności w tworzeniu migawek, operacji przechowywania, zmian sieciowych i aktualizacji konfiguracji.

Jeśli podejrzewa się eksploatację i podjęto próbę podszycia się pod tożsamość zaufanego certyfikatu, obrońcy powinni traktować potencjalne naruszenie na poziomie hosta poważnie, ponieważ Canonical potwierdza, że dostęp root może być możliwy w zależności od uprawnień tożsamości ofiary.

Reagujący na incydent powinni zachować odpowiednie dowody i sprawdzić system pod kątem trwałości, nieautoryzowanych kont lub certyfikatów, zmodyfikowanych usług, nowych obciążeń, podejrzanych procesów i nietypowej komunikacji sieciowej wychodzącej.

Organizacje korzystające z Incus zamiast z LXD Canonical powinny osobno zaktualizować do wersji Incus 7.6.0 lub odpowiedniego obsługiwanego wydania poprawionego, ponieważ powiązany projekt był dotknięty tym samym podstawowym problemem z zaufaniem łańcucha certyfikatów.

Ubuntu również zauważa, że wersje archiwalne LXD dla obecnie wymienionych wydań Ubuntu są albo nie wysyłane przez dotkniętą ścieżkę pakietu, albo nie są dotknięte, podczas gdy bezpieczeństwo skierowane przez Canonical koncentruje się na wydaniach Snap. Administratorzy powinni jednak wciąż weryfikować faktyczną dystrybucję i wersję LXD działającą w ich środowisku, zamiast zakładać narażenie tylko na podstawie wydania Ubuntu.

Zastrzeżenie: Nie wszystkie CVE mogą mieć dostępne treści związane z wykrywaniem. Sprawdź Platformę SOC Prime pod kątem bieżącego zasięgu. Jeśli odpowiednie wykrycia nie są jeszcze dostępne, sprawdzaj ponownie, gdyż nowa inteligencja o zagrożeniach i treści wykrywające są na bieżąco dodawane.