Katalog podatności CVE
Przetłumaczone opisy podatności z bazy NVD NIST - w języku polskim
Przeglądaj podatności według pakietuKatalog CISA KEV zaktualizowany: (v2026.10.21)
Cotygodniowy digest CVE
Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.
Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.
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.
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.
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.
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.
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.
Komponent Location Service for Esri w IBM Maximo Application Suite w wersjach 9.2, 9.1 i 9.0 jest podatny na niezamierzony ruch wychodzący z sieci z powodu błędnie skonfigurowanej polityki NetworkPolicy w Kubernetes.
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ą kontrolę dostępu z powodu definicji Custom Resource Definition bez schematu.
sandboxed.sh do wersji 1.3.0 zawiera podatność ucieczki z kontenera, która pozwala kodowi w obszarach roboczych kontenera uzyskać dostęp do systemu plików hosta, ponieważ nsenter jest dołączany bez opcji --root. Kod uruchamiany przez agenta w kontenerze może rozwiązywać ścieżki absolutne na hoście, aby czytać i modyfikować pliki hosta, omijając udokumentowaną izolację.
Shaark w wersjach od 1.2.13 do 1.2.44 zawiera podatność braku autoryzacji w kontrolerach API Link, Story, Chest i Album, która pomija sprawdzanie własności. Uwierzytelnieni użytkownicy niebędący administratorami mogą wysyłać żądania PUT lub DELETE do /api/{link,story,chest,album}/{id} z numerycznymi identyfikatorami, aby nadpisać lub usunąć treści innych użytkowników, w tym elementy prywatne.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

