CVE-2026-42176

Scoold to platforma Q&A i dzielenia się wiedzą dla zespołów. W wersjach przed 1.69.1 metoda checkApiAuth() w pliku ScooldUtils.java akceptuje token JWT podpisany kluczem app_secret_key lub para_secret_key dla endpointów /api/config i /api/stats bez wymagania zarejestrowanego jti klucza API i mapuje żądanie na hardkodowanego administracyjnego użytkownika API_USER. Sprawdzenia specjalnych endpointów są wykonywane nawet gdy scoold.api_enabled jest false. Atakujący, który zdobędzie jeden z sekretów podpisywania, może sfałszować token, który odczytuje wrażliwą konfigurację i logi serwera oraz osiąga uprzywilejowaną funkcjonalność konfiguracji.

Scoold to platforma Q&A i dzielenia się wiedzą dla zespołów. W wersjach przed 1.69.1 metoda apiCorsConfiguration() w pliku ScooldServer.java łączy addAllowedOriginPattern("*") z setAllowCredentials(true), powodując, że Spring odzwierciedla dowolne pochodzenie żądania, jednocześnie zezwalając na pliki cookie lub tokeny sesji. Złośliwa strona internetowa odwiedzona przez zalogowanego użytkownika Scoold może w związku z tym wysyłać uwierzytelnione żądania API, odczytywać dane użytkowników, pytania i konfigurację oraz wywoływać operacje zmieniające stan w imieniu użytkownika.

Scoold to platforma Q&A i dzielenia się wiedzą dla zespołów. W wersjach przed 1.69.1 metoda getBackToUrl() w pliku HttpUtils.java waliduje parametry backto i returnto za pomocą Strings.CI.startsWith względem skonfigurowanego adresu URL serwera. Atakujący może podać bezwzględny adres URL, którego nazwa hosta zaczyna się od legalnej nazwy hosta, powodując, że URI.resolve() zachowa adres URL atakującego, a sprawdzenie prefiksu go zaakceptuje. Ofiara, która kliknie spreparowany link logowania, może zostać przekierowana do domeny kontrolowanej przez atakującego po uwierzytelnieniu, co umożliwia phishing i potencjalną kradzież poświadczeń lub tokenów.

Scoold to platforma Q&A i wymiany wiedzy dla zespołów. Przed wersją 1.69.0 uwierzytelnieni użytkownicy niebędący członkami prywatnej przestrzeni mogą tworzyć treści w pytaniach należących do tej przestrzeni, ponieważ QuestionController.reply() i CommentController.createAjax() nie stosują sprawdzenia autoryzacji canAccessSpace używanego przez ścieżkę odczytu pytania. Przy scoold.is_default_space_public ustawionym na false i używaniu prywatnych przestrzeni użytkownik z ważną sesją i znanym lub możliwym do wyliczenia identyfikatorem pytania może wysyłać żądania do POST /question/{id} i POST /comment, powodując zapisanie odpowiedzi i komentarzy w wątku, którego nie może odczytać.

Scoold to platforma Q&A i wymiany wiedzy dla zespołów. Przed wersją 1.69.0 użytkownicy z osobistymi tokenami API mogą pobierać odpowiedzi z pytań w prywatnych przestrzeniach, do których nie mają dostępu, ponieważ ApiController.getPostReplies() nie stosuje canAccessSpace przed zwróceniem danych z GET /api/posts/{id}/answers. Problem występuje, gdy scoold.api_user_access_enabled i scoold.api_enabled są ustawione na true, a posiadacz tokena zna lub wylicza identyfikator prywatnego pytania. W takich warunkach endpoint pytania może odmówić dostępu, podczas gdy endpoint odpowiedzi zwraca treści prywatnych odpowiedzi.

Scoold, platforma Q&A i dzielenia się wiedzą dla zespołów, zawiera lukę w autoryzacji, która pozwala każdemu zalogowanemu użytkownikowi z niskimi uprawnieniami nadpisać istniejące pytanie innego użytkownika. Wystarczy podać publiczne ID pytania jako parametr postId w żądaniu POST do /questions/ask. Luka występuje przed wersją 1.66.2.

Scoold przed wersją 1.66.1 nie sprawdza uprawnień do usuwania komentarzy – każdy zalogowany użytkownik może usunąć komentarz innego użytkownika, znając jego ID. Brakuje weryfikacji własności obiektu ani uprawnień moderatora.