CVE-2026-55513

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.2.0 do przed 0.5.0, gdy OIDC jest włączone, GET /ui/oidc/login jest osiągalny bez uwierzytelnienia i jest zarejestrowany poza trasami auth z limitem szybkości w Web UI. Każde żądanie tworzy nowy losowy stan OIDC i przechowuje go w mapie w pamięci przez 10 minut. Wygasłe stany są usuwane leniwie, ale nie ma limitu szybkości ani maksymalnego limitu żywych stanów na ścieżce alokacji. Zdalny klient bez uwierzytelnienia może zatem zwiększać OIDC.states przez pełny czas TTL stanu, ograniczony przepustowością żądań, a nie skonfigurowanymi limitami szybkości auth. 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.