CVE-2026-34967

Adminer przed 6.1.1 zawiera podatność na zdalne wykonanie kodu, która pozwala uwierzytelnionym użytkownikom SQLite na ominięcie ograniczeń ATTACH i VACUUM INTO poprzez poprzedzenie instrukcji znakiem BOM UTF-8. Atakujący mogą dołączyć plik bazy danych w ścieżce serwowanej przez PHP i utworzyć tabelę z kodem PHP, aby wykonać go jako użytkownik serwera WWW.

Adminer 4.16.0 do 6.0.1 zawiera podatność SSRF przed uwierzytelnieniem w opcjonalnym sterowniku Elasticsearch (plugins/drivers/elastic.php), naprawioną w 6.0.2. Ponieważ adminer/include/auth.inc.php wywołuje Driver::connect() przed walidacją wyniku logowania, nieuwierzytelniony atakujący może wysłać spreparowane parametry auth[server], auth[username] i auth[password], powodując, że serwer Adminer wyśle żądanie HTTP GET do dowolnego osiągalnego hosta i portu. Sterownik nie blokuje adresów loopback, prywatnych, link-local ani innych zastrzeżonych; jeśli nie podano portu, dodaje domyślny 9200, a ogólna kontrola portów odrzuca porty poniżej 1024. Wybrane pola błędów JSON z odpowiedzi innych niż 2xx oraz błędy połączenia są renderowane na stronie logowania, co umożliwia skanowanie portów i rozpoznanie wewnętrznej sieci. Wymaga to wdrożenia opcjonalnego sterownika Elasticsearch i włączenia allow_url_fopen.

Adminer przed wersją 5.4.3 nie sanityzuje pola serwera przed skonstruowaniem ciągu DSN PDO, co pozwala nieuwierzytelnionym atakującym na wstrzyknięcie parametrów ODBC za pomocą średników. Atakujący może wstrzyknąć parametry TraceFile i TraceOn, aby zapisać kod PHP do katalogu głównego serwera WWW, osiągając zdalne wykonanie kodu.

Adminer 5.5.1 do 6.0.1 nieprawidłowo parsuje ciąg 'server' logowania w funkcji host_port() w adminer/include/functions.inc.php. Grupa przechwytująca port wymaga czystych cyfr zakotwiczonych na końcu ciągu, więc każda wartość serwera z niedomagającym ogonem nie spełnia wyrażenia regularnego i wraca do zwrócenia całego ciągu jako hosta z pustym portem. Ponieważ ograniczenie uprzywilejowanych portów w adminer/include/auth.inc.php sprawdza tylko sparsowany port, kontrola jest pomijana, a klient mysqli/mysqlnd następnie ponownie parsuje host:port z ciągu hosta i otwiera połączenie TCP. Zdalny, nieuwierzytelniony atakujący, który może dotrzeć do strony logowania Adminer, może przesłać spreparowaną wartość, taką jak 127.0.0.1:80/x, aby serwer zainicjował połączenia TCP do dowolnych wewnętrznych hostów i uprzywilejowanych portów przed weryfikacją poświadczeń, umożliwiając SSRF i ślepe skanowanie portów wewnętrznych (odmowa połączenia vs. handshake vs. timeout działa jako wyrocznia żywotności). To regresja, która ponownie otwiera obejście naprawione w 5.5.0 (GHSA-58cq-mgw2-38m5). Naprawione w 6.0.2.

Adminer w wersjach od 6.0.0 do 6.0.1, gdy załadowany jest oficjalny plugin sterownika ClickHouse, jest podatny na podatność Server-Side Request Forgery przed uwierzytelnieniem. Nieuwierzytelniony atakujący może przesłać auth[driver]=clickhouse z auth[server] ustawionym na dowolny URL, powodując, że serwer Adminer wyśle żądanie HTTP POST zawierające 'SELECT version()' do tego hosta. W rootQuery(), jeśli cel zwróci status poza 200-299 (inny niż 401/403), surowe ciało odpowiedzi HTTP jest przypisywane do błędu połączenia i renderowane na stronie logowania, więc atakujący otrzymuje pełne ciało odpowiedzi wewnętrznej usługi. Umożliwia to rozpoznanie wewnętrznej sieci/portów i ujawnienie poufnych informacji zawartych w wewnętrznych stronach błędów. Naprawiono w Adminer 6.0.2.

Adminer przed wersją 6.0.2 zawiera podatność cross-site scripting, gdzie wynik CONNECTION_ID() z bazy danych jest interpolowany do JavaScript bez odpowiedniego escapowania, co pozwala złośliwemu serwerowi bazy danych na wykonanie dowolnego JavaScript w uwierzytelnionym kontekście Adminer. W środowiskach współlokowanych, gdzie baza danych ma uprawnienia FILE i może zapisywać do katalogu głównego WWW, atakujący mogą użyć XSS do wysyłania uwierzytelnionych żądań SQL, które zapisują pliki PHP przez INTO DUMPFILE, osiągając zdalne wykonanie kodu jako konto serwera WWW.

Adminer przed wersją 5.4.3 używa schematu tokenów CSRF, który przesyła zarówno maskę XOR, jak i zamaskowaną wartość w każdym tokenie (format (rand XOR secret):rand), co pozwala każdemu, kto zaobserwuje pojedynczy token CSRF (np. przez podsłuch sieciowy, pliki dziennika, nagłówek Referer lub XSS), na odzyskanie sekretu sesji za pomocą pojedynczej operacji XOR i sfałszowanie nieograniczonej liczby ważnych tokenów. Implementacja jest dodatkowo osłabiona przez niskoentropijny token sesji (rand(1,1e6), ~20 bitów), który umożliwia ślepe brute-force, oraz przez użycie luźnego porównania (==) w weryfikacji tokena, co umożliwia manipulację typem w PHP. Eksploatacja umożliwia ataki CSRF na uwierzytelnione sesje, w tym wykonanie dowolnych zapytań SQL.

Adminer przed wersją 5.4.3 wstawia nieoczyszczone ciągi wersji serwera bazy danych do tagów skryptów z ważnymi nonce CSP bez odpowiedniej walidacji. Atakujący kontrolujący złośliwy serwer MySQL mogą zwrócić spreparowane ciągi wersji, które wychodzą z kontekstu JavaScript i wykonują dowolny kod, omijając zabezpieczenia Content Security Policy.

Adminer przed wersją 5.4.3 zawiera podatność na zdalne wykonanie kodu w obsłudze zapytań SQLite, gdzie polecenie VACUUM INTO nie jest blokowane mimo ograniczeń ATTACH. Uwierzytelnieni atakujący mogą wykonać VACUUM INTO, aby zapisać kod PHP do dowolnych ścieżek plików i wykonać polecenia na serwerze.