CVE-2026-111383

Nezha od wersji 2.2.5 przed 2.3.15 zawiera podatność ujawnienia informacji, która pozwala uwierzytelnionym użytkownikom odczytać poświadczenia stron trzecich, ponieważ funkcja listDDNS nie usuwa pól WebhookURL i WebhookRequestBody. Administratorzy lub tokeny PAT z zakresem nezha:ddns:read mogą wywołać GET /api/v1/ddns i odczytać tokeny w postaci jawnej.

Nezha od wersji 1.7.0 przed 2.3.15 zawiera podatność ujawnienia informacji, która pozwala uwierzytelnionym członkom wyliczać identyfikatory serwerów innych dzierżawców poprzez zróżnicowane odpowiedzi. Atakujący może skanować kolejne identyfikatory w getServerConfig i setServerConfig, odróżniając odmowę dostępu od odpowiedzi sukcesu.

Nezha od wersji 2.1.0 przed 2.3.15 zawiera podatność host header injection w mintTransferTool, która buduje adresy fs.download_url i fs.upload_url na podstawie niezwalidowanego nagłówka Host. Atakujący kontrolujący nagłówek Host w żądaniu ofiary może przekierować przesyłane pliki lub przechwycić jednorazowe tokeny pobierania.

Nezha od wersji 1.0.0 przed 2.3.15 zawiera podatność wyczerpania pamięci w punkcie końcowym WebSocket menedżera plików, ponieważ fmStream nigdy nie wywołuje SetReadLimit, pozostawiając rozmiar wiadomości nieograniczony. Uwierzytelniony użytkownik z uprawnieniami menedżera plików może wysłać jedną zbyt dużą wiadomość binarną na /api/v1/ws/file/:id, wywołując zabicie procesu przez OOM.

Nezha 2.2.3 zawiera regresję wstrzykiwania nagłówka Host w punkcie końcowym przekierowania OAuth2. Gdy opcjonalne ustawienie dashboard_host jest puste, /api/v1/oauth2/{provider} odzwierciedla nagłówek Host dostarczony przez atakującego do redirect_uri wysyłanego do dostawcy tożsamości. Atakujący może przejąć kod autoryzacyjny ofiary i przejąć konto.

Nezha od wersji 1.8.0 do 2.3.13 zawiera odwrócenie kolejności blokad w UpdateGroup i DeleteGroup, które pozwala uwierzytelnionym użytkownikom niebędącym administratorami zablokować podsystem alertów. Atakujący mogą równocześnie wywoływać punkty końcowe grup powiadomień i masowego usuwania z nadmiernie dużymi listami identyfikatorów, aby poszerzyć wyścig i zamknąć cykl ABBA, trwale zabijając dostarczanie alertów do restartu.

Nezha przed wersją 2.2.7 zawiera podatność na ujawnienie informacji w punkcie końcowym GET /api/v1/profile, który zwraca pole hasła zahashowanego bcrypt uwierzytelnionych użytkowników. Atakujący mogą wyodrębnić hashe haseł i przeprowadzić ataki offline bez ograniczeń szybkości ani śladów audytu.

Nezha to narzędzie do monitorowania serwerów i stron internetowych. W wersjach >= 2.2.11 i < 2.3.1, worker sentinel usługi (service/singleton/servicesentinel.go) zawiera niekompletną poprawkę wcześniej zgłoszonej podatności na wyłuskanie nil (denial of service) (GHSA-qjpp-gffx-2wm9). Poprawka z 2026-07-21 ponownie walidowała cykl życia usługi pod serviceResponseDataStoreLock, ale używała już przechwyconego, nieaktualnego wskaźnika reportera i nigdy nie ponownie walidowała serwera, a ten lock nie chroni ServerShared. Uwierzytelniony użytkownik z rolą członka, który posiada agenta, może wydać równoczesne usunięcie serwera (POST /api/v1/batch-delete/server) dla własnego serwera, aby wygrać wyścig, powodując wyłuskanie brakującego wpisu w migawce listy serwerów przez worker. Ponieważ workery sentinel i serwer gRPC nie mają interceptora recover()/recovery, wynikający panic jest nieodzyskany i powoduje awarię całej instancji. Poprawione w wersji 2.3.1.

Nezha w wersjach 2.0.10 do 2.3.2 używa ograniczonego klienta HTTP do walidacji konfigurowalnych przez użytkownika adresów URL webhooków powiadomień i DDNS, ale lista zablokowanych nie obejmowała zakresów przejściowych IPv6 — konkretnie prefiksu 6to4 2002::/16 oraz prefiksu translacji lokalnej IPv4/IPv6 64:ff9b:1::/48. Ponieważ takie adresy spełniają sprawdzenie netip.Addr.IsGlobalUnicast w Go, walidator URL je akceptował. Uwierzytelniony użytkownik mogący skonfigurować webhook może spowodować, że dashboard wyśle żądania do w inny sposób ograniczonego punktu końcowego IPv6, ale tylko tam, gdzie sieć dashboardu zapewnia nietypowe lub niezgodne ze standardami routowanie dla tych zakresów przejściowych; nie wykazano bezpośredniej ścieżki do żądania HTTP do metadanych IPv4, pętli zwrotnej lub sieci prywatnej. Problem jest naprawiony w wersji 2.3.3 (commit d1fcde8e), która blokuje oba prefiksy.

Nezha przed 2.3.8 nie waliduje typu reguły alertu ani zakresu czasu trwania, co pozwala uwierzytelnionym użytkownikom niebędącym administratorami tworzyć błędne reguły wywołujące nieodwracalne paniki w goroutine ewaluatora alertów. Atakujący może przesłać spreparowaną regułę przez POST /api/v1/alert-rule, powodując awarię procesu dashboardu.