CVE-2026-26379

Koha przed wersjami 26.05.02, 25.11.07 i 25.05.13 zawiera podatność na przechowywany XSS w obsłudze sugestii zakupu, która pozwala uwierzytelnionym pracownikom na wstrzykiwanie złośliwych skryptów poprzez przesłanie niesanityzowanych danych w operacji zapisu sugestii. Atakujący mogą dostarczyć spreparowane treści HTML lub skryptów w polach takich jak tytuł, autor, ISBN, kod wydawcy, miejsce, tytuł kolekcji, typ pozycji i notatka, które są przechowywane bez sanityzacji i później renderowane w szablonie listy sugestii, powodując wykonanie wstrzykniętych skryptów w przeglądarce każdego pracownika przeglądającego sugestie.

Podatność na przechowywany SQL injection w Koha do wersji 24.11.17, 25.05.12, 25.11.06 i 26.05.01. Uwierzytelniony personel z uprawnieniem borrowers => edit_borrowers może spowodować czasową odmowę usługi, przechowując ładunek SQL w polu lang patrona, który jest wykonywany podczas drukowania slipu.

Podatność na wstrzykiwanie SQL w Koha (do wersji 24.11.17, 25.05.12, 25.11.06, 26.05.01) pozwala uwierzytelnionemu personelowi z uprawnieniem acquisition => order_receive na odczyt dowolnych danych z bazy przez parametr orderby w acqui/parcels.pl. Parametr jest przekazywany do C4::Acquisition::GetInvoices, gdzie kierunek sortowania jest konkatenowany do klauzuli ORDER BY bez walidacji. Atak jest ślepy (czasowy) i umożliwia wyodrębnienie danych osobowych czytelników, hashy haseł personelu i sekretów 2FA.

Podatność na przechowywany SQL injection w Koha do wersji 24.11.17, 25.05.12, 25.11.06 i 26.05.01. Uwierzytelniony personel z uprawnieniem tools => label_creator może wykonać dowolny SQL przez pole image_name w układzie karty patrona, co pozwala na odczyt całej bazy danych, w tym danych osobowych i skrótów haseł.

Podatność na trwałe wstrzykiwanie SQL w Koha (do wersji 24.11.17, 25.05.12, 25.11.06, 26.05.01) pozwala uwierzytelnionemu personelowi z uprawnieniem tools => items_batchmod na odczyt dowolnych danych z bazy przez przechowywanie ładunku SQL w wartości agefield reguły automatycznej modyfikacji przedmiotów. Wartość jest przechowywana bez zmian i interpolowana do zapytania SQL w C4::Items::ToggleNewStatus podczas wykonywania zaplanowanego zadania cron. Atak umożliwia odczyt całej bazy Koha, w tym danych osobowych czytelników i hashy haseł personelu.

Kreator raportów w systemie Koha (reports/guided_reports.pl) odczytuje parametry CGI i bezpośrednio konkatenuje je do klauzuli SQL ORDER BY bez żadnej listy dozwolonych wartości ani walidacji. Ponieważ kolumny ORDER BY nie mogą być wiązane przez przygotowane zapytania, wymagana jest jawna lista dozwolonych, która nie istnieje.

Raport statystyk obiegu w Koha (reports/issues_stats.pl) buduje zapytanie obliczeniowe w podprogramie calculate, łącząc kilka kontrolowanych przez użytkownika parametrów żądania bezpośrednio w ciąg SQL. Parametry PeriodTypeSel, PeriodDaySel i PeriodMonthSel są interpolowane surowo do fragmentów równości w pojedynczych cudzysłowach i porównań funkcji, a sloty Filter oraz identyfikatory Line i Column są również interpolowane bez białej listy i bez wiązania parametrów.

Raport reports/bor_issues_top.pl w Koha buduje dynamiczne SQL w podprogramie calculate, łącząc kilka kontrolowanych przez użytkownika parametrów żądania bezpośrednio w ciąg zapytania. Uwierzytelniony pracownik z uprawnieniami do modułu raportów może wstrzyknąć dowolny SQL i odczytać dowolną tabelę dostępną dla użytkownika bazy danych Koha, w tym borrowers (hasła, sekrety dwuskładnikowe, dane osobowe), api_keys i sesje.

Raport reports/issues_avg_stats.pl w Koha buduje dynamiczne SQL w podprogramie calculate, łącząc kilka kontrolowanych przez użytkownika parametrów żądania bezpośrednio w ciąg zapytania. Parametry Line i Column nie są weryfikowane względem żadnej białej listy i trafiają dosłownie w pozycje identyfikatorów (SELECT DISTINCTROW, GROUP BY, ORDER BY), a każdy slot Filter jest łączony surowo w fragmenty LIKE, BETWEEN i porównań w pojedynczych cudzysłowach bez powiązanych parametrów.

Podatność w Koha w skrypcie reports/catalogue_stats.pl, gdzie dynamiczne zapytanie SQL jest budowane przez interpolację kontrolowanych przez użytkownika parametrów Line i Column bezpośrednio w pozycjach identyfikatorów zapytania (SELECT DISTINCTROW, GROUP BY, ORDER BY) bez walidacji na białej liście.