CVE-2026-55512

Podatność w nebula-mesh umożliwia eskalację uprawnień poprzez brak odpowiedniej kontroli dostępu na wielu endpointach API. Każdy operator z kluczem API może uzyskać dostęp do zasobów innych operatorów.

nebula-mesh (wersje od 0.6.0 do przed 0.7.2) umożliwia operatorom bez uprawnień administratora (rola user) ustawienie allow_private: true na własnych subskrypcjach webhook (POST/PATCH /api/v1/webhook-subscriptions). Brakuje kontroli administracyjnej na tym polu. Podczas dostarczania webhooka, allow_private przełącza dyspozytora na niechroniony klient HTTP, omijając zabezpieczenia SSRF dla adresów prywatnych/pętli zwrotnej/link-local, co pozwala operatorowi o niskich uprawnieniach na zmuszenie serwera do żądań wewnętrznych adresów.

nebula-mesh przed wersją 0.7.1 ma lukę, gdzie odwołanie (revocation) jest jedynym mechanizmem izolacji skompromitowanego hosta. Ponieważ lista zablokowanych nie dociera do plików config.yml żadnego peera, zablokowany host zachowuje pełną dostępność do wszystkich peerów w swojej sieci przez okres do 30 dni (agent) lub 365 dni (mobile). Atakujący, który wykradnie host.key+host.crt, może uruchomić standardowe slackhq/nebula bezpośrednio, ignorując odpowiedzi agenta 403/410, i pozostać połączonym po odwołaniu hosta przez operatora.

nebula-mesh to samodzielnie hostowany panel sterowania dla Slack Nebula mesh VPN. Od wersji 0.3.0 do przed 0.5.0, ścieżka tworzenia hosta w interfejsie Web UI nebula-mgmt ignoruje zarówno ustawienie bezpieczeństwa enrollment_token_ttl dla całego serwera, jak i nadpisania per-network network_config.enrollment_token_ttl. API tworzenia hosta i ścieżki regeneracji tokenów używają skonfigurowanego resolvera TTL, ale POST /ui/hosts twardo koduje now.Add(24 * time.Hour) dla nowo utworzonych tokenów rejestracji agenta. W środowiskach, które celowo skracają czas życia tokenów rejestracji, każdy uwierzytelniony operator, który może utworzyć hosta przez Web UI, może nadal wygenerować token rejestracji nośnika ważny przez około 24 godziny. Problem został naprawiony w wersji 0.5.0.

nebula-mesh przed wersją 0.3.8 ma lukę w obsłudze webowej, gdzie renderMobileBundle przekazuje rzeczywisty *pki.CAResolver do mobilebundle.Build. W Build, resolver.LoadByID odszyfrowuje prywatny klucz ed25519 CA do *pki.CAManager, ale Build nigdy nie wywołuje CAManager.Wipe() na żadnej ścieżce powrotu. W rezultacie, gdy żądanie mobilnego pakietu przechodzi przez web UI i Build zwraca (szczególnie przy błędzie), klucz prywatny CA pozostaje w pamięci Go, nieusunięty, aż do garbage collection. Atakujący, który może odczytać pamięć procesu (core dump, swap, skanowanie pamięci), może odzyskać klucz podpisujący CA, co pozwoliłoby na tworzenie dowolnych certyfikatów hosta dla sieci mesh.

nebula-mesh przed wersją 0.3.8 przechowuje tokeny sesji operatora w postaci jawnego tekstu w tabeli operator_sessions (kolumna token jest kluczem głównym). Token sesji to 32-bajtowa losowa wartość hex wysyłana bezpośrednio w ciasteczku i ważna przez 24 godziny. Każdy, kto może odczytać bazę danych (backup, snapshot, kopia pliku, lub wyciek na poziomie SQL), uzyskuje wszystkie aktywne tokeny sesji i może przejąć sesje operatora bez dodatkowego uwierzytelnienia.

nebula-mesh przed wersją 0.3.7 ma dwie luki autoryzacyjne: blocklista nie jest sprawdzana przy podpisywaniu/ponownej rejestracji certyfikatu (kluczowana po odcisku palca, więc ponowna rejestracja tworzy nowy odcisk), a odnowienie certyfikatu nie weryfikuje ponownie statusu operatora ani CA. Host, który nie powinien być już zaufany, może uzyskać nowy ważny certyfikat Nebula.

Nebula Mesh w wersjach 0.3.5 i niższych nie stosuje ograniczeń CA dla operatorów w interfejsie web UI, co pozwala uwierzytelnionemu operatorowi niebędącemu administratorem na dostęp do zasobów innych operatorów. Luka została częściowo zaadresowana w GHSA-598g-h2vc-h5vg, ale nie objęła interfejsu web.

nebula-mesh przed wersją 0.3.2 ustawia flagi HttpOnly i SameSite=Lax na ciasteczkach, ale nigdy nie ustawia flagi Secure. Pojedyncze żądanie w czystym tekście do origin (np. operator w LAN, błędnie wpisany URL, brak ścisłego wymuszania HTTP→HTTPS, błędna konfiguracja reverse proxy) ujawnia sesję.

W nebula-mesh przed wersją 0.3.2 nowo wygenerowany klucz API operatora był ujawniany w adresie URL przekierowania, co mogło prowadzić do wycieku w nagłówku Referer, historii przeglądarki lub logach proxy. Problem został naprawiony w wersji 0.3.2.