Katalog podatności CVE

W pgAdmin 4 przed wersją 9.19, gdy serwer nie miał skonfigurowanego pliku haseł, certyfikatu klienta lub klucza klienta albo wskazany plik nie istniał, pgAdmin pomijał parametr w połączeniu, a libpq używał domyślnych plików konta systemowego uruchamiającego pgAdmin. W trybie serwera każdy użytkownik mógł więc łączyć się z serwerem przy użyciu zapisanych haseł lub certyfikatu konta usługi.

W pgAdmin 4 hasło serwera było zapisywane w środowisku procesu pgAdmin (jako PGPASSWORD dla narzędzia PSQL oraz pod zmienną per-proces dla narzędzia) i nigdy nie usuwane. W trybie serwera środowisko jest współdzielone przez żądania wszystkich użytkowników i kopiowane do uruchamianych procesów, więc inny użytkownik mógł odziedziczyć hasło i użyć go do połączenia.

W pgAdmin 4 w trybie serwera libpq wyszukuje usługi połączeń w pliku usług konta systemowego, co pozwala użytkownikom na użycie poświadczeń lub plików certyfikatów tego konta. Podatność dotyczy wersji przed 9.19 i może prowadzić do nieautoryzowanego dostępu do serwerów baz danych.

W pgAdmin 4 w trybie serwera usunięcie KRB5CCNAME powodowało, że biblioteka Kerberos używała domyślnego cache poświadczeń konta systemowego, umożliwiając każdemu użytkownikowi połączenie jako principal usługi. Podatność dotyczy wersji przed 9.19 i obejmuje również obejście gssencmode=disable oraz zachowanie SSPI w Windows.

W pgAdmin 4 w trybie serwera ścieżka binarna ustawiona przez użytkownika nie była weryfikowana względem katalogów SHARED_STORAGE, co pozwalało na przesłanie pliku wykonywalnego i uruchomienie go jako konto systemowe pgAdmin. Podatność jest szczególnie istotna w Windows, gdzie pliki mogą być wykonywalne, i dotyczy wersji przed 9.19.

W pgAdmin 4 w trybie serwera biblioteka sshtunnel zawsze ładowała niezaszyfrowane klucze prywatne z ~/.ssh konta systemowego i czytała jego konfigurację SSH, umożliwiając każdemu użytkownikowi skonfigurowanie tunelu z użyciem tożsamości konta usługi. Podatność dotyczy wersji przed 9.19.

pgAdmin 4 przed wersją 9.19 zawiera obejście poprawki CVE-2026-17566 w narzędziu Import/Export Data. Nieprawidłowa walidacja ukośnika w podwójnie cytowanym identyfikatorze pozwala ukryć nawias zamykający i wykonać klauzulę TO PROGRAM przez psql na hoście pgAdmin z uprawnieniami konta systemowego.

W trybie serwera pgAdmin 4 występuje luka w walidacji ścieżek: funkcja check_access_permission() sprawdzała jedną ścieżkę, a wywołujący używali innej, co pozwalało na odczyt, zapis, usuwanie lub przenoszenie plików poza katalogiem przechowywania użytkownika. Dodatkowo podwójne dekodowanie ścieżek folderów i brak separatora przy łączeniu ścieżek umożliwiały dostęp do katalogów innych użytkowników lub całego systemu. Podatność dotyczy wersji pgAdmin 4 przed 9.19 i nie występuje w trybie desktop.

W trybie serwera pgAdmin 4 prowadzi osobne konta dla każdego źródła uwierzytelniania, więc ta sama nazwa użytkownika może istnieć jako konto wewnętrzne i LDAP. Po uwierzytelnieniu przez LDAP lub Kerberos pgAdmin wybierał konto do zalogowania wyłącznie na podstawie nazwy użytkownika, bez sprawdzenia źródła uwierzytelnienia, co pozwalało na przejęcie sesji innego konta wraz z jego rolami, serwerami i zapisanymi hasłami do baz danych.

W trybie serwerowym pgAdmin 4 mechanizm blokady konta wewnętrznego po przekroczeniu limitu nieudanych logowań (domyślnie 3) można obejść na kilka sposobów. Luki w widokach Flask-Security, w dopasowywaniu nazwy użytkownika (wielkość liter) oraz w interakcji z innymi źródłami uwierzytelniania (LDAP, webserver, Kerberos) pozwalają nieuwierzytelnionemu atakującemu na nieograniczone zgadywanie haseł do dowolnego konta wewnętrznego, w tym administratora. Dodatkowo możliwe są nieautoryzowane resetowania haseł i ujawnienie konfiguracji serwera w oknie About.

W wersjach Secret Server on-prem starszych niż 12.3.1 użytkownik w określonych warunkach mógł przesłać niepodpisany JWT i w odpowiedzi otrzymać uprawnienia cloudadmin. Umożliwia to eskalację uprawnień do poziomu administracyjnego.

W wersjach Secret Server on-prem starszych niż 12.3.1 użytkownik mógł spowodować wygenerowanie kodu PIN drugiego czynnika dla dowolnego konta bez wcześniejszego uwierzytelnienia, a następnie pominąć początkowy etap logowania i uwierzytelnić się wyłącznie drugim czynnikiem.

W wersjach Secret Server on-prem starszych niż 12.3.1 aplikacja nie zawsze weryfikowała kod PIN ani kontrolę biometryczną podczas korzystania z urządzenia zgodnego z FIDO2. Może to pozwolić na obejście dodatkowego czynnika uwierzytelniania.

Wtyczka WordPress All In One Login w wersjach do 2.4.1 zawiera podatność na cross-site scripting (XSS), którą można wykorzystać bez uwierzytelnienia.

Wtyczka WordPress LeadSnap w wersjach do 1.25 zawiera podatność na wstrzyknięcie obiektu PHP (PHP Object Injection), którą można wykorzystać bez uwierzytelnienia.

Podatność typu cross-origin request forgery w WIT SynApps Runtime do wersji 1.4.11 pozwalająca atakującym podać dowolny adres docelowy podczas wdrażania kontrolera, co powoduje wysyłanie przez przeglądarkę ofiary żądań odkrywania do hostów wskazanych przez atakującego. Atakujący może wykorzystać przeglądarkę ofiary do sondowania adresów loopback, lokalnych nazw hostów lub hostów wewnętrznych i inicjowania procesu rejestracji w instancjach REDY, przekraczając granice segmentacji IT/OT.

Podatność typu pre-authentication reflected cross-site scripting w WIT SynApps Runtime do wersji 1.4.11 pozwalająca nieuwierzytelnionym atakującym wstrzyknąć i wykonać dowolny JavaScript poprzez spreparowany parametr zapytania LINK wysłany do punktu końcowego /System/Session-1. Atakujący mogą wykorzystać tę lukę do przechwytywania poświadczeń, manipulacji procesem logowania, dostępu do danych widocznych w przeglądarce i wykonywania żądań same-origin do punktów końcowych kontrolera.

WIT SynApps Runtime do wersji 1.4.11 zawiera podatność związaną z zaszytymi na stałe poświadczeniami. Statyczne wartości OAuth clientId i clientSecret są osadzone w JavaScripcie dostarczanym do frontendu (np. w parameters.js), co pozwala nieuwierzytelnionemu atakującemu je odzyskać.

Wtyczka WordPress GS Testimonial Slider w wersjach do 3.3.10 zawiera podatność na wstrzyknięcie obiektu PHP (PHP Object Injection) możliwą do wykorzystania przez użytkownika z rolą współautora.

W silniku zapytań jednostopniowych Apache Pinot występuje luka w autoryzacji. Gdy włączona jest kontrola dostępu brokera, silnik autoryzuje tylko tabelę wymienioną w klauzuli FROM zapytania, pomijając tabelę wymiaru wskazywaną przez funkcję `lookup()`. Uwierzytelniony użytkownik uprawniony do co najmniej jednej tabeli może odczytywać kolumny z dowolnej tabeli wymiaru w klastrze, w tym tabel, do których nie ma dostępu, oraz pobierać dowolne wiersze, podając wartości klucza głównego. Filtry bezpieczeństwa na poziomie wiersza również nie są stosowane. Luka dotyczy wersji do 1.5.1 i została naprawiona w 1.6.0.