Katalog podatności CVE

IBM TRIRIGA Application Platform w wersjach od 5.0.0 do 5.0.8 może pozwolić zdalnemu uwierzytelnionemu atakującemu na wykonanie dowolnego kodu z powodu nieprawidłowej walidacji ścieżek plików podczas rozpakowywania archiwów.

W Frappe ERPNext przed wersją 14.92.1 oraz w gałęzi 15.x przed 15.83.0 występuje luka odbitego skryptu krzyżowego (reflected XSS) z powodu braku walidacji danych wejściowych na pewnej stronie, co pozwala na wykonanie dowolnego JavaScriptu w uwierzytelnionych sesjach. Zdalny atakujący może nakłonić zalogowanego użytkownika do otwarcia spreparowanego adresu URL, aby wykonać wstrzyknięty skrypt i przejąć konto ofiary.

W Frappe przed wersją 14.81.4 oraz w gałęzi 15.x przed 15.41.0 występuje luka nieprawidłowego zarządzania uprawnieniami dotycząca pewnej akcji dokumentu, która pozwala na eskalację z roli Website User do System Manager. Uwierzytelniony atakujący z dostępem Website User może połączyć tę akcję z dodatkowymi krokami, aby uzyskać administracyjne uprawnienia System Manager w aplikacji Frappe.

IBM Maximo Application Suite - komponent IoT w wersjach 9.2.0, 9.1.0 i 9.0.0 może pozwolić zdalnemu atakującemu na wywołanie odmowy usługi (DoS) z powodu niekontrolowanej rekurencji.

IBM Maximo AI Service 9.1.0 i 9.2.0 może pozwolić zdalnemu atakującemu na wywołanie odmowy usługi z powodu nieprawidłowego obsługiwania uszkodzonych ramek, co prowadzi do zakończenia procesu hosta.

IBM Maximo AI Service 9.1.0 i 9.2.0 SaaS może pozwolić zdalnemu atakującemu na wywołanie odmowy usługi z powodu niekontrolowanej rekurencji.

IBM Maximo AI Service 9.1.0 i 9.2.0 może pozwolić zdalnemu atakującemu na wywołanie odmowy usługi z powodu niekontrolowanego zużycia zasobów.

Nginx UI przed wersją 2.4.1 używa stałej wartości OAuth state w GetCasdoorUri i nie weryfikuje stanu w CasdoorCallback, co pozwala nieuwierzytelnionemu atakującemu na przejęcie sesji użytkownika.

Code for IBMi przed wersją 3.0.1 akceptuje komponenty IBMi bez weryfikacji integralności, co pozwala lokalnemu kontu na modyfikację programów i wykonanie ich pod kontem łączącego się użytkownika.

IBM Power Systems Firmware FW1060.00 do FW1060.81 ma podatność w parsowaniu konfiguracji firmware hosta, umożliwiającą atakującemu z dostępem serwisowym do FSP spowodowanie uszkodzenia pamięci podczas IPL, co narusza integralność bootowania i hiperwizora.

IBM Power Systems Firmware FW1060.00 do FW1060.81 ma podatność w interfejsie mailbox procesora serwisowego, umożliwiającą atakującemu z dostępem serwisowym do FSP odczyt i modyfikację pamięci Hostboot, co narusza integralność bootowania i hiperwizora.

IBM Power Systems Firmware FW1060.00 do FW1060.81 ma podatność w interfejsie mailbox procesora serwisowego, umożliwiającą atakującemu z dostępem serwisowym do FSP przepełnienie pamięci atrybutów runtime firmware hosta, co pozwala na wykonanie dowolnego kodu w runtime firmware.

IBM Power Systems Firmware FW1120.00 do FW1120.01, FW1110.00 do FW1110.31 i FW1060.00 do FW1060.81 ma podatność w ścieżce walidacji obrazu podczas procesu bootowania, umożliwiającą atakującemu z dostępem serwisowym do procesora serwisowego dostarczenie złośliwego obrazu aktualizacji kodu, co pozwala na wykonanie dowolnego kodu na hoście.

IBM Power Systems Firmware FW1060.00 do FW1060.81 ma podatność w interfejsie mailbox procesora serwisowego, umożliwiającą atakującemu z dostępem serwisowym do FSP przepełnienie pamięci atrybutów runtime firmware hosta, co pozwala na wykonanie dowolnego kodu w runtime firmware.

Oprogramowanie układowe IBM Power Systems w wersjach FW1060.00 do FW1060.81 zawiera podatność w analizie konfiguracji oprogramowania układowego hosta. Atakujący z uwierzytelnionym dostępem na poziomie usług do procesora usług może zapisać specjalnie spreparowane dane konfiguracyjne, powodując awarię stosu rozruchowego oprogramowania układowego hosta z możliwym uszkodzeniem pamięci podczas inicjalizacji systemu, co wpływa na integralność i dostępność zarządzanego systemu.

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