CVE-2026-54677

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

W Scoold przed wersją 1.67.0 można zmodyfikować wartość konfiguracji admins poprzez /api/config/set/admins przy użyciu sfałszowanego tokena Bearer akceptowanego jako token API administratora. Po zmianie docelowy adres e-mail jest zapisywany w pliku konfiguracyjnym aplikacji, a po restarcie Scoold wybrany użytkownik jest uznawany za administratora i uzyskuje dostęp do panelu administracyjnego. Luka daje atakującemu niezawodną ścieżkę trwałego dostępu. Została naprawiona w wersji 1.67.0.

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.