CVE-2026-53602
ŚrednieCVSS 6.9Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 13 - wyżej niż 13% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Niezaufany host może uzyskać ważny certyfikat VPN, co pozwala na nieautoryzowany dostęp do sieci mesh. Zablokowani operatorzy mogą nadal wystawiać certyfikaty.
Rekomendacja
Zaktualizować nebula-mesh do wersji 0.3.7 lub nowszej, która naprawia obie luki autoryzacyjne.
Inne podatności w nebula-mesh
Zobacz wszystkie- CVE-2026-47724Krytyczne
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.
- CVE-2026-63464Wysokie
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.
- CVE-2026-61699Wysokie
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.
- CVE-2026-55513Średnie
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.
- CVE-2026-55512Średnie
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.
- CVE-2026-53604Wysokie
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.
- CVE-2026-53603Wysokie
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.
- CVE-2026-49258Wysokie
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.
- CVE-2026-48058Średnie
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ę.
- CVE-2026-47768Średnie
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.
Oryginalny opis (angielski, źródło NVD)
nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. Prior to version 0.3.7, two related authorization gaps let a host that should no longer be trusted obtain a fresh, valid Nebula certificate, because nebula-mgmt does not re-evaluate revocation/authorization state at certificate issuance time — only at poll time. Firstly, the blocklist is not enforced at sign / re-enroll time. internal/api/enroll.go:128 calls caMgr.Sign(...) without consulting the blocklist. The blocklist is only checked in the poll path (internal/api/updates.go:57, fingerprintInBlocklist). The blocklist is keyed by certificate fingerprint (internal/store/sqlite.go), so a re-enrollment produces a new fingerprint that is not in the blocklist. Secondly, renewal does not re-validate operator / CA status. Auto-renewal at poll time (internal/api/updates.go:285-319, signHostCert) reads host.Name, host.Groups, host.NebulaIPs from the DB and re-signs without checking whether the owning operator is still active or the CA still valid. DisableOperator (internal/store/sqlite_operators.go) revokes sessions and API keys but does not retire the operator's CAs, and pki/signer.go checks only CA cert time-expiry, not operator/CA status. This issue has been patched in version 0.3.7.