CVE-2026-105112

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 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.