CVE-2026-119575

ArcadeDB od wersji 21.12.1 przed 26.10.2 zawiera podatność obejścia autoryzacji, która pozwala użytkownikom posiadającym jedynie readRecord zastąpić współdzielony schemat GraphQL poprzez punkt końcowy zapytań tylko do odczytu. Atakujący może wysłać definicję typu GraphQL z spreparowaną dyrektywą @sql do /api/v1/query/{database}, zmieniając wyniki zapytań zwracane innym użytkownikom, w tym administratorom.

ArcadeDB (com.arcadedb:arcadedb-engine) do 26.8.1 egzekwuje reguły kontroli dostępu per typ/rekord tylko w LocalBucket, opierając się na identyfikatorze pliku. Ścieżki wykonywania zapytań, które docierają do danych przez pliki indeksu LSM lub silnik TimeSeries, nie wywołują tego sprawdzenia, więc uwierzytelniony użytkownik bez uprawnień readRecord/deleteRecord może odczytać wartości kluczy indeksu, identyfikatory rekordów, wartości MAX/MIN, próbki TimeSeries, poznać liczbę rekordów i usuwać wpisy indeksu, co desynchronizuje indeks z danymi. Nazwy indeksów i typów są odkrywalne przez SELECT FROM schema:indexes. Problem dotyczy wdrożeń embedded i serwerowych oraz wszystkich transportów. Naprawiono w 26.9.1.

ArcadeDB przed wersją 26.8.1 zawiera podatność braku uwierzytelnienia w pluginie Redis wire-protocol, co pozwala nieuwierzytelnionym atakującym na odczyt, zapis i usuwanie danych. Atakujący mogą łączyć się z portem Redis i wykonywać dowolne polecenia na dowolnej bazie danych bez podawania poświadczeń.

ArcadeDB przed wersją 26.8.1 nie egzekwuje uwierzytelniania SASL dla poleceń danych w pluginie MongoDB wire-protocol. Nieuwierzytelnieni atakujący mogą wydawać polecenia insert, find, update, delete i create na dowolnej bazie danych, łącząc się z portem 27017 bez poświadczeń.

Serwer ArcadeDB (com.arcadedb:arcadedb-server) w wersjach 26.7.3 i wcześniejszych nie propaguje uwierzytelnionego podmiotu do asynchronicznych wątków roboczych poleceń. Gdy polecenie HTTP jest wysyłane z awaitResponse:false, wykonuje się na asynchronicznym workerze, którego DatabaseContext nie ma powiązanego użytkownika, co powoduje, że brama autoryzacji skryptów staje się nieaktywna. Użytkownik z dostępem tylko do odczytu do jednej bazy danych może wysłać asynchroniczne polecenie JavaScript (language=js) przez endpoint /api/v1/command, aby uruchomić kod z nieograniczonym dostępem do hosta (np. database.getSecurity().createUser) i utworzyć administratora całego serwera, eskalując do pełnej kontroli administracyjnej. Naprawione w wersji 26.8.1.

ArcadeDB przed wersją 26.8.1 nie wiąże uwierzytelnionego podmiotu z wątkiem wykonawcy transakcji gRPC w beginTransaction, co pozwala uwierzytelnionym użytkownikom z prawami odczytu na wykonywanie poleceń JavaScript bez kontroli autoryzacji skryptów. Atakujący mogą wykonać executeCommand z identyfikatorem transakcji, aby uruchomić nieograniczony JavaScript tworzący konta administratora całego serwera.

ArcadeDB przed wersją 26.7.2 zawiera podatność na ominięcie autoryzacji w handlerach HTTP dla endpointów szeregów czasowych, batch, Prometheus i Grafana. Atakujący może uzyskać dostęp do baz danych i modyfikować je bez odpowiednich uprawnień, wywołując bezpośrednio podatne endpointy z dowolnymi parametrami bazy danych.

ArcadeDB przed wersją 26.7.2 nie egzekwuje kontroli autoryzacji skryptów dla instrukcji SQL DEFINE FUNCTION z językiem js. Atakujący z dostępem do bazy danych może wykonać dowolny kod JavaScript, przesyłając instrukcje DEFINE FUNCTION, omijając zabezpieczenia ograniczające skryptowanie do administratorów.

ArcadeDB w wersjach od 21.10.1 do 26.4.1 zawiera dwie wady: (1) funkcja ServerSecurityUser.getDatabaseUser() zwraca użytkownika bazy z niezainicjalizowaną mapą dostępu do plików, co powoduje zezwolenie na wszystko; (2) metoda ArcadeDBServer.createDatabase() pomija ustawienie factory.setSecurity(...), przez co nowo utworzona baza danych ma wyłączoną autoryzację na poziomie rekordów. Uwierzytelniony użytkownik lub token API może odczytywać, zapisywać i modyfikować schemat w dowolnej bazie na tym samym serwerze.

ArcadeDB przed wersją 26.10.2 zawiera podatność nieprawidłowej autoryzacji, która pozwala unieważnionym użytkownikom zachować dostęp poprzez już otwarte połączenia protokołów Postgres, Bolt, MongoDB lub Redis. Atakujący posiadający istniejące połączenie może nadal czytać i zapisywać dane po usunięciu konta, odebraniu uprawnień lub zmianie hasła, ponieważ executery przechowują nieaktualny ServerSecurityUser.