CVE-2026-55442

Goobi viewer to aplikacja webowa umożliwiająca wyświetlanie zdigitalizowanych materiałów w przeglądarce. Od wersji 22.04 do przed 26.05 nieuwierzytelniony endpoint REST GET /api/v1/index/{solrField}/spatial/search konkatenuje parametr zapytania region podany przez użytkownika bezpośrednio do ciągu zapytania Solr bez escapowania, usuwania parametrów lokalnych i wymuszania schematu w czasie wykonywania. Atakujący może wstrzyknąć składnię parametrów lokalnych Solr ({!parent ...}, {!join ...}) i operatory logiczne, aby dopasować rekordy georeferencyjne o ograniczonym dostępie, omijając filtr warunków dostępu. Problem został naprawiony w wersji 26.05.

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