CVE-2026-50160

Hoppscotch: mass assignment w endpoincie onboardingu umożliwia przejęcie serwera

CVSS 10.0v3.1pub. 2026-07-01upd. 2026-07-02

Niezabezpieczony endpoint POST /v1/onboarding/config w Hoppscotch (samodzielnie hostowane wdrożenia) pozwala nieuwierzytelnionemu atakującemu nadpisać krytyczne wartości konfiguracyjne, w tym klucze JWT i sesji. Skutkuje to możliwością fałszowania tokenów dla dowolnego użytkownika, łącznie z administratorami, co prowadzi do pełnego przejęcia serwera.

▸ Pokaż oryginał (EN)

Hoppscotch is an API development ecosystem. In self-hosted deployments of hoppscotch-backend from version 2026.4.1 and earlier, the unauthenticated POST /v1/onboarding/config endpoint is vulnerable to mass assignment. The global NestJS ValidationPipe is configured without whitelist: true, so extra properties on the request body that are not declared in SaveOnboardingConfigRequest are not stripped and are iterated in the service layer as if they were legitimate InfraConfig entries. Because keys such as JWT_SECRET and SESSION_SECRET are valid InfraConfigEnum values and are not explicitly rejected during validation, an unauthenticated attacker who can reach a fresh instance before onboarding completes (or when no users exist) can overwrite these values in the database. Overwriting JWT_SECRET gives the attacker control of the JWT signing key, allowing them to forge tokens for any user, including administrators, and results in full server compromise. The issue is fixed in hoppscotch 2026.5.0.

🤖 Analiza AI

Jak działa

Globalny mechanizm walidacji NestJS (ValidationPipe) jest skonfigurowany bez opcji whitelist: true, przez co dodatkowe właściwości przesyłane w ciele żądania nie są usuwane przed przetworzeniem. Klucze takie jak JWT_SECRET i SESSION_SECRET są poprawnymi wartościami InfraConfigEnum i nie są jawnie odrzucane podczas walidacji, więc trafiają do warstwy serwisowej jako legalne wpisy konfiguracyjne. Nieuwierzytelniony atakujący może wysłać żądanie do endpointu onboardingowego (dostępnego przed zakończeniem konfiguracji lub gdy nie istnieje żaden użytkownik) i nadpisać te wartości bezpośrednio w bazie danych. Po przejęciu JWT_SECRET atakujący zyskuje pełną kontrolę nad procesem podpisywania tokenów JWT i może wystawiać prawidłowe tokeny dla dowolnego konta.

Skutki

Atakujący może sfałszować tokeny JWT dla dowolnego użytkownika, w tym administratorów, co skutkuje pełnym przejęciem serwera oraz uzyskaniem nieautoryzowanego dostępu do wszystkich danych i funkcji aplikacji.

Mitygacja

Należy zaktualizować Hoppscotch do wersji 2026.5.0, w której problem został naprawiony. Jako doraźne zabezpieczenie należy ograniczyć dostęp sieciowy do endpointu POST /v1/onboarding/config oraz upewnić się, że proces onboardingu został zakończony (istnieje co najmniej jeden użytkownik w systemie).

Kogo dotyczy

Samodzielnie hostowane wdrożenia hoppscotch-backend w wersji 2026.4.1 i wcześniejszych, dostępne przed zakończeniem procesu onboardingu lub gdy nie istnieje żaden użytkownik w systemie.

Uwagi

Podatność dotyczy wyłącznie okna czasowego przed zakończeniem procesu onboardingu lub gdy w instancji nie istnieje żaden użytkownik. Poprawka została opublikowana w ramach pull requesta #6171 oraz opisana w oficjalnym security advisory GHSA-j542-4rch-8hwf.