CVE-2026-101087
ŚrednieCVSS 4.3Streszczenie
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.
Ocena ryzyka
Ryzyko obejmuje możliwość wysyłania żądań do wewnętrznych lub zastrzeżonych zasobów IPv6 przez skonfigurowany webhook, co może prowadzić do nieautoryzowanego dostępu do danych lub usług w specyficznych warunkach sieciowych.
Rekomendacja
Zaleca się aktualizację Nezha do wersji 2.3.3 lub nowszej, która zawiera poprawkę blokującą te prefiksy.
Inne podatności w Nezha
Zobacz wszystkie- CVE-2026-101089Niskie
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.
- CVE-2026-101088Średnie
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.
- CVE-2026-101085Średnie
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.
- CVE-2026-101090Krytyczne
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.
Oryginalny opis (angielski, źródło NVD)
Nezha versions 2.0.10 through 2.3.2 use a restricted HTTP client to validate user-configurable notification and DDNS webhook URLs, but the denylist did not cover IPv6 transition ranges — specifically the 6to4 prefix 2002::/16 and the local-use IPv4/IPv6 translation prefix 64:ff9b:1::/48. Because such addresses satisfy Go's netip.Addr.IsGlobalUnicast check, the URL validator accepted them. An authenticated user able to configure a webhook may be able to cause the dashboard to issue requests to an otherwise restricted IPv6 endpoint, but only where the dashboard's network provides unusual or non-standards-compliant routing for these transition ranges; no direct path to an IPv4 metadata, loopback, or private-network HTTP request has been demonstrated. The issue is fixed in version 2.3.3 (commit d1fcde8e), which blocks both prefixes.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS