Katalog podatności CVE

Podatność walidacji callbacku OAuth1 w Apache Allura. Problem dotyczy Apache Allura do wersji 1.21.0. Użytkownicy powinni zaktualizować do wersji 1.22.0, która naprawia problem.

Nginx UI to interfejs webowy dla serwera Nginx. Przed wersją 2.4.1 trasy mutacji konfiguracji HTTP wymagają RequireSecureSession, ale /mcp i /mcp_message wymagają tylko zwykłego uwierzytelnienia przed udostępnieniem nginx_config_add i nginx_config_modify. Użytkownik z włączonym OTP, posiadający zwykły JWT, ale bez ważnego X-Secure-Session-ID, może tworzyć lub modyfikować konfigurację Nginx i wywoływać przeładowanie przez MCP, omijając zamierzoną kontrolę step-up. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1 zawiera podatność, w której wygenerowane krótkie tokeny nie mają powiązanej długiej wartości Token, a funkcja DeleteUserTokens unieważnia wpisy w pamięci podręcznej tylko wtedy, gdy długie pole Token nie jest puste. Odwołany krótki token może pozostać w pamięci podręcznej i ponownie uwierzytelnić użytkownika, jeśli konto zostanie ponownie włączone przed wygaśnięciem wpisu, przywracając dostęp do tras HTTP lub WebSocket akceptujących uwierzytelnianie krótkim tokenem.

Nginx UI przed wersją 2.4.3 zawiera podatność polegającą na tym, że funkcja AutoBackup.GetName zwraca nazwę kontrolowaną przez użytkownika bez odrzucania separatorów ścieżek lub komponentów katalogu nadrzędnego, a dalsze formatowanie nazwy pliku osadza ten wynik w końcowej nazwie archiwum. Uwierzytelniony użytkownik może spowodować, że filepath.Join rozwiąże wygenerowaną ścieżkę archiwum poza zwalidowanym katalogiem przechowywania, umożliwiając zapis archiwów kopii zapasowych z uprawnieniami procesu Nginx UI.

Nginx UI przed wersją 2.4.1 odrzuca w zwykłym API konfiguracji HTTP ograniczone dyrektywy Nginx, takie jak load_module, js_import i js_content. Jednak interfejs konfiguracji MCP pozwala uwierzytelnionemu użytkownikowi zapisać i zastosować równoważną ograniczoną zawartość konfiguracji. Umożliwia to załadowanie ngx_http_js_module.so, importowanie kontrolowanego przez atakującego JavaScriptu, przeładowanie Nginx i wykonanie NJS w kontekście workerów Nginx. Problem naprawiono w wersji 2.4.1.

Nginx UI od wersji 2.0.0-rc.6 do 2.4.1, narzędzie MCP nginx_config_add zapisuje pliki konfiguracyjne Nginx na dysk i wyzwala przeładowanie Nginx bez wywołania config.ValidateConfigFile. Identyczny przepływ w API REST (POST /api/configs) wywołuje tę funkcję i poprawnie odrzuca niebezpieczne dyrektywy. Uwierzytelniony atakujący może wykorzystać tę lukę do zapisania plików konfiguracyjnych zawierających dowolną zablokowaną dyrektywę (perl, js_import, load_module, user root itp.), omijając całą warstwę bezpieczeństwa nginx-ui. Na serwerze z modułem Perl, njs lub Lua Nginx jest to zdalne wykonanie kodu po uwierzytelnieniu. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, wewnętrzny plik config/validation.go (ValidateConfigFile) jest kontrolą bezpieczeństwa blokującą niebezpieczne dyrektywy nginx — js_*, perl_*, load_module modułów njs/perl oraz user root. Jest egzekwowany na trzech z czterech ścieżek zapisu konfiguracji: api/config/add.go, api/config/modify.go i mcp/config/config_modify.go. Czwarta ścieżka — narzędzie MCP nginx_config_add (mcp/config/config_add.go) — NIE wywołuje tej funkcji: zapisuje dostarczoną przez wywołującego zawartość bezpośrednio na dysk i przeładowuje nginx. Uwierzytelniony wywołujący MCP (lub agent MCP zaindukowany przez prompt injection) może więc wstrzyknąć dokładnie te dyrektywy, które kontrola ma blokować, prowadząc do wykonania kodu nginx na wdrożeniach, gdzie dostępny jest moduł njs/perl (np. oficjalny obraz Docker). Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, config.ValidateConfigDirectives dzieli konfigurację po nowych liniach i sprawdza tylko pierwszy token dyrektywy w każdej linii, mimo że Nginx dopuszcza wiele dyrektyw oddzielonych średnikami w jednej linii. Uwierzytelniony wywołujący może umieścić nieszkodliwą dyrektywę na początku, a później w tej samej linii ograniczoną dyrektywę load_module, js_import, perl lub user root, albo użyć nieograniczonej dyrektywy include do załadowania ograniczonej zawartości. Te mechanizmy omijają walidację na ścieżkach zapisu REST, nginx_config_modify, site i stream; gdy dostępny jest moduł wykonywalny, wstrzyknięta konfiguracja może wykonać kod w kontekście workerów Nginx. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1 nie stosuje RequireSecureSession do wielu uwierzytelnionych tras mutacji, mimo że użytkownicy z włączonym OTP powinni przedstawić świeży X-Secure-Session-ID do wrażliwych działań. Wykradziona uwierzytelniona sesja może zatem tworzyć lub zmieniać automatyczne kopie zapasowe, dane uwierzytelniające i rekordy DNS, certyfikaty i użytkowników ACME, ustawienia sterowania Nginx oraz automatyzację site lub stream bez ukończenia kroku OTP lub passkey. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, endpoint POST /api/users/:id umożliwia uwierzytelnionemu użytkownikowi zmianę hasła innego użytkownika bez przejścia RequireSecureSession, mimo że ścieżka samodzielnej zmiany hasła wymaga tego kroku. Atakujący z uwierzytelnionym kontem może zmienić hasło początkowego administratora, unieważnić istniejące tokeny administratora, a następnie uwierzytelnić się jako administrator. Problem naprawiono w wersji 2.4.1.

Nginx UI przed wersją 2.4.1, POST /api/otp_enroll i POST /api/finish_passkey_register są zarejestrowane poza RequireSecureSession i akceptują normalną uwierzytelnioną sesję bez weryfikacji bieżącego hasła. Atakujący z wykradzionym JWT może powiązać kontrolowany przez siebie sekret TOTP, gdy ofiara nie włączyła jeszcze TOTP, lub zarejestrować kontrolowany passkey, ponieważ ta ścieżka nie ma odpowiedniego zabezpieczenia istniejącej rejestracji. Te zmiany tworzą trwały dostęp do konta, który może przetrwać zmianę hasła i zakłócić uwierzytelnianie prawowitego użytkownika. Problem naprawiono w wersji 2.4.1.

IBM Maximo AI Service w wersjach 9.1.0 i 9.2.0 może pozwolić zdalnemu atakującemu na spowodowanie odmowy usługi z powodu nieprawidłowej walidacji danych wejściowych.

Komponent IoT w IBM Maximo Application Suite w wersjach 9.2.0, 9.1.0 i 9.0.0 zawiera podatność pozwalającą zdalnemu atakującemu wywołać odmowę usługi. Przyczyną jest nieskończona pętla parsowania podczas przetwarzania określonych danych wejściowych.

Ten numer CVE został odrzucony lub wycofany przez jego CVE Numbering Authority.

Portal del Hermano (portaldelhermano.es) przed 2026-10-06 zawiera podatność złamanej autoryzacji w procesie odzyskiwania hasła na endpointach POST /password/create-access i POST /password/email. Brak limitu prób oraz różne komunikaty błędów działające jak wyrocznie dla czterech czynników weryfikacji tożsamości (DNI, data urodzenia, numer telefonu, ostatnie cztery cyfry IBAN) pozwalają nieuwierzytelnionemu atakującemu przejąć dowolne konto członka we wszystkich dzierżawach.

OWASP Coraza WAF od wersji 3.4.0 do 3.8.0 zawiera podatność w procesorze multipart, który traktuje błąd io.ErrUnexpectedEOF jako niekrytyczny bez ustawiania MULTIPART_STRICT_ERROR. Zdalny atakujący może wysłać obcięte ciało multipart, powodując zatrzymanie parsowania bez podniesienia sygnału błędu ścisłego używanego przez zalecaną regułę obronną, co pozwala na dotarcie do backendu z payloadami wykorzystującymi niezgodność parsera.

OWASP Coraza WAF od wersji 3.0.0 do 3.8.0 zawiera podatność w natywnym formacie dziennika audytu, który zapisuje pola żądań i odpowiedzi kontrolowane przez atakującego bez neutralizowania znaków powrotu karetki lub nowej linii. Gdy włączony jest SecAuditLogFormat Native, wstrzyknięte znaki nowej linii mogą tworzyć sfałszowane linie wewnątrz rekordu transakcji, co może wprowadzić w błąd operatorów i przetwarzanie SIEM.

Komponent Location Service for Esri w IBM Maximo Application Suite w wersjach 9.2, 9.1 i 9.0 jest podatny na niewłaściwą walidację danych wejściowych z powodu nieoczyszczonego odwołania do obrazu kontenera w szablonie operatora Kubernetes.

IBM Maximo Application Suite - Location Service for Esri Component w wersjach 9.2, 9.1 i 9.0 jest podatny na nieprawidłową walidację danych wejściowych z powodu nieoczyszczonej konfiguracji obrazu kontenera w szablonie operatora Kubernetes.

Komponent Location Service for Esri w IBM Maximo Application Suite w wersjach 9.2, 9.1 i 9.0 jest podatny na wstrzyknięcie poleceń z powodu niewłaściwego oczyszczenia wartości kontrolowanej przez użytkownika przekazywanej do polecenia powłoki w zadaniu operatora Kubernetes.