Podatności CSRF i LDAP Injection w bibliotece PAC4J. Aktualizacja pilnie zalecana

CERT Polska poinformował o dwóch poważnych podatnościach w bibliotece PAC4J, popularnym frameworku Java służącym do uwierzytelniania i autoryzacji w aplikacjach webowych. Obie luki zostały zgłoszone do zespołu CERT Polska, który koordynował proces ujawniania informacji. Administratorzy systemów wykorzystujących PAC4J powinni jak najszybciej zaktualizować oprogramowanie do bezpiecznych wersji.

Obejście ochrony CSRF przez kolizje hashCode

Pierwsza z podatności, oznaczona jako CVE-2026-40458, dotyczy mechanizmu ochrony przed atakami Cross-Site Request Forgery. Problem występuje w wersjach od 5.0 do 5.7.10 oraz od 6.0 do 6.4.1. Atakujący może przygotować złośliwą stronę internetową, która po odwiedzeniu przez ofiarę wysyła sfałszowane żądanie z tokenem kolidującym z prawdziwym tokenem CSRF.

Kluczowym elementem ataku jest wykorzystanie słabości deterministycznej funkcji String.hashCode() w Javie. Kolizje można obliczać w locie, co skutecznie obniża przestrzeń tokenu do zaledwie 32 bitów. Atakujący nie musi wcześniej znać tokenu ani jego hasha – wystarczy, że wygeneruje wartość powodującą kolizję.

W praktyce osoba atakująca może wykonać operacje w imieniu zalogowanego użytkownika bez jego wiedzy i zgody. CERT Polska wskazuje, że możliwe scenariusze obejmują zmianę profilu użytkownika, modyfikację hasła czy łączenie kont. Problem został naprawiony w wersjach 5.7.10 i 6.4.1.

LDAP Injection w wielu miejscach biblioteki

Druga podatność, CVE-2026-40459, ma jeszcze szerszy zakres oddziaływania. Dotyczy wersji od 4.0 do 4.5.10, od 5.0 do 5.7.10 oraz od 6.0 do 6.4.1. Zidentyfikowano w bibliotece luki typu LDAP Injection występujące w wielu miejscach kodu.

Zdalny atakujący o niskich uprawnieniach może wstrzyknąć spreparowaną składnię LDAP do parametrów wyszukiwania opartych na identyfikatorze. Skutkiem może być wykonywanie nieautoryzowanych zapytań LDAP oraz dowolnych operacji na katalogu. W środowiskach korporacyjnych, gdzie LDAP często służy do zarządzania użytkownikami i uprawnieniami, konsekwencje mogą być poważne.

Problem został naprawiony w wersjach 4.5.10, 5.7.10 i 6.4.1. Administratorzy powinni niezwłocznie zaktualizować bibliotekę do jednej z bezpiecznych wersji, odpowiedniej dla używanej gałęzi rozwojowej.

Koordynacja ujawnienia przez CERT Polska

Obie podatności zostały zgłoszone do CERT Polska, który koordynował proces odpowiedzialnego ujawniania informacji. Zespół CERT Polska publicznie podziękował Bartłomiejowi Dmitrukowi z firmy striga.ai za zgłoszenie luk. Proces CVD (Coordinated Vulnerability Disclosure) pozwolił producentowi na przygotowanie poprawek przed publicznym ujawnieniem szczegółów.

Na moment publikacji ostrzeżenia nie ma informacji o aktywnym wykorzystywaniu tych podatności w atakach. Jednak ze względu na popularność biblioteki PAC4J w środowiskach Java oraz stosunkowo niski poziom skomplikowania ataków, szczególnie w przypadku LDAP Injection, ryzyko należy traktować poważnie.

Co powinni zrobić administratorzy

Pierwszym krokiem jest identyfikacja systemów wykorzystujących bibliotekę PAC4J. Framework jest szeroko stosowany w aplikacjach Java do integracji z różnymi mechanizmami uwierzytelniania, w tym OAuth, SAML, CAS, OpenID Connect i LDAP. Administratorzy powinni sprawdzić zależności projektów i wersje używanych bibliotek.

Następnie należy zaktualizować PAC4J do bezpiecznej wersji odpowiedniej dla używanej gałęzi: 4.5.10 dla wersji 4.x, 5.7.10 dla wersji 5.x lub 6.4.1 dla wersji 6.x. Po aktualizacji warto przeprowadzić testy regresyjne, aby upewnić się, że zmiana nie wpłynęła negatywnie na działanie aplikacji.

W przypadku systemów, w których natychmiastowa aktualizacja nie jest możliwa, należy rozważyć tymczasowe środki zaradcze. Dla CVE-2026-40458 może to obejmować dodatkową walidację żądań na poziomie aplikacji lub infrastruktury. Dla CVE-2026-40459 zaleca się wzmocnić monitorowanie zapytań LDAP i wprowadzić dodatkową walidację danych wejściowych.

Szerszy kontekst bezpieczeństwa bibliotek

Przypadek PAC4J przypomina o konieczności regularnego monitorowania bezpieczeństwa używanych bibliotek i frameworków. Podatności w popularnych komponentach mogą dotknąć setki lub tysiące aplikacji jednocześnie. Organizacje powinny wdrożyć procesy śledzenia biuletynów bezpieczeństwa i szybkiego reagowania na ujawnione luki.

Warto również zwrócić uwagę na jakość mechanizmów bezpieczeństwa w używanych bibliotekach. Problem z funkcją hashCode() przy tokenach CSRF pokazuje, że nawet pozornie bezpieczne rozwiązania mogą zawierać subtelne słabości. Regularne audyty bezpieczeństwa kodu, zarówno własnego, jak i zewnętrznych zależności, pozostają kluczowym elementem obrony.