CVE-2026-120046

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 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 od wersji 2.0.13 przed 2.3.15 zawiera podatność wyczerpania zasobów, która pozwala uwierzytelnionym użytkownikom otwierać nieograniczoną liczbę równoczesnych połączeń do punktu końcowego WebSocket /api/v1/ws/transfer. Atakujący może utrzymywać tysiące subskrypcji tworzonych przez ServerTransferClass.Subscribe, wyczerpując deskryptory plików, pamięć i goroutines.

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.