Katalog podatności CVE

Zilliz Attu przed wersją 3.0.0 ma funkcję Playground, która nie wymaga uwierzytelnienia do proxy dowolnych żądań HTTP i HTTPS do URL-i w publicznym internecie.

Funkcja Playground w Zilliz Attu przed wersją 3.0.0 umożliwia SSRF (proxy żądań do prywatnych adresów IP).

Interfejs programowania aplikacji WebSocket nie ma ograniczeń dotyczących liczby żądań uwierzytelnienia. Brak limitowania tempa może pozwolić atakującemu na przeprowadzenie ataków typu denial-of-service lub ataków brute-force w celu uzyskania nieautoryzowanego dostępu.

Backend WebSocket używa identyfikatorów stacji ładowania do jednoznacznego kojarzenia sesji, ale pozwala wielu punktom końcowym na połączenie przy użyciu tego samego identyfikatora sesji. Ta implementacja skutkuje przewidywalnymi identyfikatorami sesji. Podatność ta może pozwolić nieautoryzowanym użytkownikom na uwierzytelnienie jako inni użytkownicy lub umożliwić złośliwemu aktorowi przeprowadzenie ataku typu denial-of-service poprzez przeciążenie backendu prawidłowymi żądaniami sesji.

Punkty końcowe WebSocket nie posiadają właściwych mechanizmów uwierzytelniania, co umożliwia atakującym podszywanie się pod stacje ładowania. Wykorzystując tę słabość, atakujący mogą uzyskać nieautoryzowany dostęp do danych wrażliwych lub wykonywać nieautoryzowane działania. Ponieważ uwierzytelnianie nie jest wymagane, może to prowadzić do eskalacji uprawnień i potencjalnej kompromitacji całego systemu.

Broker komunikatów Armatura One loguje poświadczenia klienta i powiązane hasło w postaci zwykłego tekstu podczas normalnej operacji. Każda strona mająca dostęp do tego logu, kopii zapasowej lub pakietu wsparcia może uzyskać zalogowane poświadczenia.

Procedura tworzenia kopii zapasowej i przywracania Armatura One zapisuje pełne polecenie połączenia z bazą danych, w tym hasło superużytkownika, w postaci zwykłego tekstu w pliku dziennika na hoście. Ujawnione poświadczenia mogą być użyte do dostępu do bazy danych, gdy dostęp do systemu operacyjnego serwera jest możliwy.

Procedura inicjalizacji bazy danych Armatura One przypisuje stałe, zdefiniowane przez producenta hasło do konta superużytkownika bazy danych w momencie tworzenia, zamiast generować unikalne hasło dla każdej instalacji. Osoba z dostępem do systemu operacyjnego serwera i znajomością tej wartości może uwierzytelnić się jako superużytkownik bazy danych w instalacji, gdzie hasło nie zostało zmienione.

Armatura One przechowuje poświadczenia bazy danych i brokera komunikatów w pliku konfiguracyjnym instalacji, szyfrując je za pomocą AES-128-CBC, gdy ta ochrona jest włączona. Klucz szyfrowania i wektor inicjalizacyjny są stałymi wartościami osadzonymi w oprogramowaniu i są identyczne we wszystkich instalacjach. Atakujący z kopią pakietu instalacyjnego może odzyskać ten klucz i wektor inicjalizacyjny, a następnie odszyfrować przechowywane poświadczenia dowolnej konkretnej instalacji, do której uzyska osobno zaszyfrowany plik konfiguracyjny.

Identyfikatory uwierzytelniające stacji ładowania są publicznie dostępne za pośrednictwem internetowych platform mapowych.

Kentico Xperience 13 przed wersją 13.0.216 nie ma kontroli autoryzacji na poziomie obiektów dla punktów końcowych API administracyjnych.

MathWorks Simulink przed wersją R2026b, podczas wyświetlania spreparowanego pliku .slx, może zawierać bloki, które nigdy nie są widoczne w edytorze Simulink, ale powodują wykonanie kodu.

Ten identyfikator CVE został odrzucony i nie należy go używać. Jest duplikatem CVE-2026-78409 — wszyscy użytkownicy CVE powinni odwoływać się do CVE-2026-78409 zamiast do tego kandydata.

Ten identyfikator CVE został odrzucony i nie należy go używać. Jest duplikatem CVE-2026-78410 — wszyscy użytkownicy CVE powinni odwoływać się do CVE-2026-78410 zamiast do tego kandydata.

UTMStack w wersjach przed 11.2.16 zawiera podatność na wstrzyknięcie JPQL. Uwierzytelniony atakujący może odczytać dowolne dane encji, wstrzykując złośliwe zapytanie JPQL przez parametr value w punkcie końcowym GET /api/utm-network-scans/searchPropertyValues, ponieważ zapytanie jest budowane przez String.format() bez wiązania parametrów.

UTMStack przed wersją 11.2.16 zawiera podatność na podrabianie żądań po stronie serwera (SSRF), która pozwala uwierzytelnionym atakującym na zmuszenie serwera do żądania dowolnych wewnętrznych zasobów poprzez podanie niezweryfikowanego parametru url w metodzie PdfService.downloadPdf() udostępnianej przez GET /api/generate-pdf-report. Atakujący mogą to wykorzystać do zmuszenia mikroserwisu web-pdf do pobierania wewnętrznych punktów końcowych backendu, klastra OpenSearch lub usługi metadanych instancji chmury, ujawniając wrażliwe dane wewnętrzne renderowane w zwracanym pliku PDF.

UTMStack w wersjach przed 11.2.16 zawiera podatność na enumerację kont. Nieuwierzytelniony atakujący może ustalić zarejestrowane adresy e-mail, obserwując różne odpowiedzi HTTP z punktu końcowego POST /api/account/reset-password/init.

UTMStack w wersjach przed 11.2.16 zawiera podatność obejścia uwierzytelniania, która pozwala zdalnym atakującym uzyskać pełny dostęp administracyjny do API poprzez przedstawienie nagłówka Utm-Internal-Key zgodnego ze zmienną środowiskową INTERNAL_KEY. Filtr InternalApiKeyFilter akceptuje ten klucz dla dowolnego punktu końcowego bez ograniczeń ścieżki, porównania w stałym czasie, ograniczania liczby prób ani rejestrowania audytu. Atakujący, który pozna wartość klucza, może uwierzytelnić się bez konta użytkownika lub JWT, tworzyć konta, zarządzać użytkownikami, eksfiltrować dane i modyfikować reguły bezpieczeństwa.

UTMStack w wersjach przed 11.2.16 zawiera podatność braku autoryzacji w metodzie UTMIncidentCommandWebsocket.processCommand(), obsługującej cel STOMP /command/{hostname}, gdzie przed przekazaniem dostarczonych poleceń nie stosuje się sprawdzenia roli ani listy dozwolonych poleceń. Każdy uwierzytelniony użytkownik, niezależnie od roli, może wysyłać dowolne polecenia systemu operacyjnego przez gRPC do dowolnego podłączonego agenta, co skutkuje wykonaniem poleceń na monitorowanych punktach końcowych, gdzie procesy agenta często działają jako root lub SYSTEM.

Specjalnie spreparowane żądanie HTTP POST skierowane do interfejsu administracji webowej pozwala nieuwierzytelnionemu atakującemu na wykonanie dowolnych poleceń systemu operacyjnego z uprawnieniami root na podatnym urządzeniu. Zaleca się wyłączenie serwera webowego, gdy urządzenie nie jest konfigurowane.