Katalog podatności CVE

Wtyczka Html5 Audio Player od bPlugins do wersji 2.8.8 ma podatność na przechowywany XSS (Cross-site Scripting) z powodu niewłaściwej neutralizacji danych wejściowych podczas generowania strony. Problem dotyczy Html5 Audio Player od wersji n/a do 2.8.8.

Podatność wtyczki WordPress All Bootstrap Blocks do wersji 1.3.31 umożliwia ujawnienie wrażliwych informacji systemowych nieautoryzowanym podmiotom. Atakujący może wykorzystać ten problem do odczytania osadzonych danych wrażliwych.

Wtyczka Asgaros Forum do wersji 3.4.0 zawiera brak autoryzacji, co pozwala na wykorzystanie nieprawidłowo skonfigurowanych poziomów kontroli dostępu. Osoba atakująca może uzyskać nieautoryzowany dostęp do funkcji forum.

Wtyczka AI Translation for Polylang do wersji 1.6.2 ma brak autoryzacji, co pozwala na wykorzystanie nieprawidłowo skonfigurowanych poziomów kontroli dostępu. Atakujący może uzyskać nieautoryzowany dostęp do funkcji tłumaczenia.

Wtyczka Super Payments dla WordPressa przed wersją 1.43.1 nie weryfikuje poprawnie autentyczności przychodzących powiadomień webhook o płatnościach, ponieważ klucz podpisu jest domyślnie pusty. Umożliwia to nieuwierzytelnionym atakującym sfałszowanie podpisu i oznaczenie dowolnych zamówień WooCommerce jako opłaconych bez płatności.

W Apache CXF komponent STSTokenValidator przechowywał wynik weryfikacji podpisu asercji SAML w obiekcie współdzielonym przez wszystkie żądania, umożliwiając jednemu żądaniu odczytanie wyniku innego. Zdalny, nieuwierzytelniony atakujący mógł wysłać sfałszowaną asercję podpisaną niezaufanym certyfikatem, która została zaakceptowana jako zaufana bez weryfikacji w STS. Problem dotyczy wyłącznie usług używających STSTokenValidator bez ustawienia alwaysValidateToSts.

STSTokenValidator i Security Token Service (STS) w Apache CXF buforowały zwalidowane tokeny bezpieczeństwa przy użyciu niekryptograficznego 32-bitowego skrótu (Java Arrays.hashCode/hashCode()) i traktowały trafienie w pamięć podręczną jako dowód walidacji. Atakujący mógł stworzyć token (np. UsernameToken lub samopodpisana asercja SAML) którego skrót koliduje z wpisem w pamięci podręcznej, co pozwalało na akceptację tokenu bez weryfikacji hasła, zaufania podpisu czy wywołania STS. Mogło to umożliwić atakującemu uwierzytelnienie jako inny użytkownik i uzyskanie tokenów podpisanych przez STS dla tej tożsamości.

Parser zapytań FIQL w Apache CXF ma podatność w sposobie wyszukiwania operatorów w wyrażeniach zapytań. Wzorzec wyszukiwania może utknąć próbując wielu kombinacji przy długim ciągu bez operatora, powodując nadmierne zużycie CPU. Atakujący może wysłać spreparowane zapytanie, aby zużyć zasoby CPU serwera, potencjalnie spowalniając lub zatrzymując inne żądania. Poprawka ogranicza wyrażenia FIQL do 4 KiB domyślnie.

Komponent OIDC relying-party w Apache CXF może przekierowywać użytkowników na adres URL kontrolowany przez atakującego po pomyślnym uwierzytelnieniu. Problem występuje, ponieważ parametry stanu kontrolowane przez atakującego są zachowywane i później używane jako cele przekierowania bez walidacji, że końcowy zdekodowany URI należy do origin RP. Zarówno bezpośrednio zakodowane, jak i podwójnie zakodowane zewnętrzne adresy URL mogą wywołać problem.

Metoda CompressionUtils.inflate() dekompresowała dane DEFLATE kontrolowane przez atakującego bez limitu rozmiaru wyjściowego. Mały (~KB) spreparowany ładunek mógł rozrosnąć się do gigabajtów na stercie. Było to osiągalne przez deszyfrowanie JWE gdy zip=DEF (np. JoseSessionTokenProvider z RSA-OAEP) oraz przez inflację tokenów SAML redirect/POST binding — w obu przypadkach dekompresja następuje przed lub niezależnie od walidacji zaufania. Poprawka dodaje konfigurowalny limit maksymalnego rozmiaru (domyślnie 10 MiB).

Nieprawidłowe egzekwowanie semantyki jednorazowego kodu autoryzacyjnego w dostawcy grantu OAuth2 JPA w Apache CXF pozwala zdalnemu atakującemu uzyskać wiele ważnych tokenów dostępu z jednego kodu autoryzacyjnego poprzez równoczesne żądania wymiany tokenów, które wykorzystują wyścig w nieatomowej operacji find-then-delete na współdzielonej relacyjnej bazie danych w izolacji READ_COMMITTED.

Sprawdzenie świeżości uwierzytelnienia max_age w OidcClientCodeRequestFilter było nieskuteczne z powodu niezgodności jednostek (milisekundy/sekundy) i odwróconej polaryzacji porównania. Każda relying party używająca setMaxAgeOffset do wymuszania ponownego uwierzytelnienia cicho akceptowała sesje o dowolnym wieku, omijając polityki step-up authentication.

Domyślnie StaxUtils nie nakładał limitu na całkowitą liczbę elementów ani znaków w dokumencie XML. Bardzo duże żądanie mogło zużyć dużo pamięci i CPU podczas parsowania, szczególnie gdy CXF buduje DOM z wejścia (np. SAAJ lub WS-Security), i mogło spowodować denial of service, gdy nie skonfigurowano limitu rozmiaru żądania. Obecnie oba limity mają wartości domyślne: maksymalna liczba elementów to 100 × maxChildElements (domyślnie 5 000 000), a maksymalny rozmiar dokumentu to 256M znaków.

W Apache CXF transport klienta HTTP oparty na Netty (cxf-rt-transports-http-netty-client) nie weryfikował, czy nazwa hosta w certyfikacie TLS serwera odpowiada nazwie wywoływanego hosta. Dotyczyło to zarówno HTTP/1.1, jak i HTTP/2, nawet gdy disableCNCheck pozostawało na domyślnej wartości false. Łańcuch certyfikatów był walidowany względem skonfigurowanego trust store, ale tożsamość punktu końcowego nie była. Atakujący w sieci mogący przechwycić ruch mógł przedstawić dowolny certyfikat zaufany przez klienta, np. publicznie wydany certyfikat dla kontrolowanej domeny, i podszyć się pod usługę docelową. Mógł następnie czytać lub modyfikować wymieniane wiadomości, w tym poświadczenia.

Parser nagłówków części załączników multipart/MTOM w Apache CXF nie egzekwował w pełni limitów rozmiaru i liczby nagłówków. Ograniczenie rozmiaru dotyczyło tylko pojedynczych linii, a nie wartości złożonych z linii kontynuacji ani łącznej wartości powtarzanych nagłówków. Zdalny, nieuwierzytelniony atakujący może wysłać żądanie z bardzo dużymi nagłówkami, powodując niekontrolowaną alokację pamięci i odmowę usługi.

Moduł JAX-RS XML Security w Apache CXF nie weryfikował poprawnie podpisu XML. Interceptory podpisów XML nie zapewniały, że XML przekazany do aplikacji jest objęty podpisem. Atakujący z dokumentem podpisanym przez zaufany klucz może opakować go w niepodpisane treści, które aplikacja uzna za podpisane.

Wtyczka EduAdmin Booking (eduadmin-booking) firmy MultiNet Interactive AB zawiera lukę SQL Injection (niewłaściwa neutralizacja specjalnych elementów w komendach SQL). Umożliwia ona atakującemu przeprowadzenie ślepej iniekcji SQL. Problem dotyczy wersji od n/a do przed 6.0.0.

Podatność Reflected Cross-Site Scripting (XSS) w wtyczce Welcart e-Commerce usc-e-shop dla WordPressa, występująca w wersjach do 2.12.3 włącznie, pozwala atakującemu na wstrzyknięcie złośliwego skryptu do strony.

Podatność Cross-Site Request Forgery (CSRF) w wtyczce Featured Image from URL (featured-image-from-url) dla WordPressa, występująca w wersjach do 6.0.7 włącznie, pozwala atakującemu na wymuszenie wykonania nieautoryzowanych działań przez zalogowanego użytkownika.

Podatność Reflected Cross-Site Scripting (XSS) w wtyczce NEX-Forms (nex-forms-express-wp-form-builder) dla WordPressa, występująca w wersjach do 9.3.1 włącznie, pozwala atakującemu na wstrzyknięcie złośliwego skryptu do strony.