CVE-2026-55465

W aplikacji Goobi viewer kilka endpointów Jakarta WebSocket (DownloadTaskEndpoint, CampaignEndpoint, AutocompleteEndpoint, UserEndpoint) akceptuje połączenia bez weryfikacji, czy powiązana sesja HttpSession należy do zalogowanego użytkownika, oraz nie waliduje nagłówka Origin względem listy dozwolonych. Nieuwierzytelniony atakujący może połączyć się z tymi endpointami, a poprzez CampaignEndpoint zanieczyścić mapę blokad stron crowdsourcingu i rozgłaszać sfałszowane komunikaty blokad, zakłócając pracę recenzentów.

W Goobi viewer od wersji 25.01 do przed 26.05 metoda AuthenticationEndpoint.verifyOpenIdToken nie wymusza sprawdzenia roszczenia aud podczas walidacji kryptograficznej, a ręczne sprawdzenie obsługuje tylko pojedynczy łańcuch aud. W konfiguracji z wieloma RP token wydany dla innej strony ufającej może uwierzytelnić atakującego.

W Goobi viewer przed wersją 26.05 metoda Configuration.getWebApiToken zwraca pusty łańcuch, gdy token nie jest skonfigurowany, a AuthorizationFilter porównuje dostarczony token z tym domyślnym bez sprawdzenia, czy skonfigurowany token jest niepusty. Żądanie do chronionego punktu końcowego z pustym parametrem ?token= jest akceptowane.

W Goobi viewer starszy servlet RSS (RssResolver, GET /rss/) przyjmuje parametry q i filterQuery i konkatenuje je do zapytań Solr bez walidacji. Parametr q tworzy główną treść zapytania (owiniętą jedynie w nawiasy literalne), a filterQuery jest przekazywany bezpośrednio jako Solr fq. Nieuwierzytelniony atakujący może wstrzyknąć operatory logiczne Solr, aby wyjść z owinięcia i uczynić końcowy filtr warunków dostępu opcjonalnym, przez co rekordy o ograniczonym dostępie trafiają do generowanego kanału RSS.

W Goobi viewer funkcja SolrTools.cleanUpQuery() usuwa składnię parametrów lokalnych Solr ({!...}) z zapytań użytkownika przed przekazaniem ich do Solr. Wyrażenie regularne można obejść, owijając parametr lokalny w dodatkową parę nawiasów klamrowych ({{!...}}): zewnętrzne nawiasy są usuwane, wewnętrzny {!...} pozostaje nienaruszony i prawidłowy parametr lokalny Solr jest przekazywany dalej. Wada dotyczy wspólnego sanitizera, więc wpływa na każdy endpoint kierujący dane użytkownika przez cleanUpQuery.

W Goobi viewer przed wersją 26.05, po odwiedzeniu linku resetowania hasła aplikacja generuje hasło zastępcze w przewidywalny sposób i wysyła je e-mailem do właściciela konta. Niewystarczająca entropia pozwala atakującemu, który potrafi oszacować czas generowania po stronie serwera, na złamanie hasła metodą brute-force.

W Goobi viewer przed wersją 26.05 token resetowania hasła jest przewidywalnie oparty na czasie żądania resetu. Atakujący, który zna adres e-mail celu, może zażądać resetu, a następnie złamać token metodą brute-force. Wykorzystanie tej podatności samo w sobie wymusza nieautoryzowany reset hasła dowolnego konta.

W Goobi viewer od wersji 25.08 do przed 26.05 punkty końcowe IIIF Auth 2.0 auth/login i auth/token przyjmują parametr origin bez walidacji, który jest następnie osadzany w nagłówku Content-Security-Policy oraz w treści HTML jako argument postMessage. Ponieważ atakujący kontroluje oba wywołania, nieescapowana wartość prowadzi do odbitego XSS.

W Goobi viewer od wersji 24.03 do przed 26.05 metoda ExternalFilesDownloader.getFilename() pobiera nazwę pliku z nagłówka Content-Disposition i przekazuje ją bezpośrednio do Path.resolve() bez usuwania komponentów katalogu. Złośliwy serwer HTTP może podać ścieżkę absolutną lub sekwencje ../, zapisując treść w dowolnej lokalizacji, co prowadzi do zdalnego wykonania kodu.

W Goobi viewer od wersji 24.03 do przed 26.05 punkt końcowy WebSocket DownloadTaskEndpoint (/tasks/download/monitor.socket) w goobi-viewer-core przyjmuje żądania pobierania od nieuwierzytelnionych użytkowników. Podatność została naprawiona w wersji 26.05.