Podatności ArcadeDB

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 od wersji 26.8.1 przed 26.10.2 zawiera podatność server-side request forgery, która pozwala uwierzytelnionym użytkownikom z uprawnieniem updateDatabaseSettings wyłączyć listę blokowanych adresów IP dla LOAD CSV poprzez ALTER DATABASE. Atakujący może ustawić arcadedb.opencypher.loadCsv.blockedIpRanges na pusty ciąg, a następnie wysyłać żądania LOAD CSV w celu odczytu metadanych chmury oraz wewnętrznych usług loopback lub prywatnych.

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.

ArcadeDB w wersjach przed 26.10.1 zawiera podatność na zdalne wykonanie kodu (RCE). Uwierzytelnieni użytkownicy, w tym posiadacze roli tylko do odczytu, mogą wykonywać kod Groovy, ponieważ GremlinQueryEngine.command() nie sprawdza uprawnień do skryptów. Atakujący mogą wysyłać polecenia Gremlin do endpointu POST /api/v1/command/{database}, gdy silnik Groovy jest włączony, i uruchamiać polecenia systemowe jako użytkownik procesu serwera.

ArcadeDB od wersji 26.2.1 przed 26.10.1 zawiera podatność braku autoryzacji w obsłudze protokołu Bolt, która pozwala uwierzytelnionym użytkownikom odczytywać metadane schematów innych baz danych. Atakujący posiadający poświadczenia do jednej bazy danych może ustawić pole db w komunikatach RUN lub BEGIN i wywołać db.labels() lub SHOW INDEXES, aby wyliczyć nieautoryzowane schematy.

ArcadeDB od wersji 26.2.1 przed 26.10.1 zawiera podatność braku autoryzacji w obsłudze protokołu Bolt, która pozwala uwierzytelnionym użytkownikom wyliczyć nazwy wszystkich baz danych. Atakujący posiadający poświadczenia do dowolnej pojedynczej bazy danych może wykonać zapytanie SHOW DATABASES przez port Bolt, aby ujawnić nieautoryzowane nazwy baz danych, eksponując identyfikatory dzierżawców lub projektów.

ArcadeDB od wersji 26.8.1 przed 26.10.1 zawiera podatność obejścia autoryzacji, która pozwala użytkownikom z uprawnieniami tylko do odczytu modyfikować flagi schematu lightweight i unique typów krawędzi bez uprawnienia UPDATE_SCHEMA. Atakujący może wysłać polecenie ALTER TYPE edgeType WITH lightweight = true przez API HTTP, gRPC lub Bolt, aby trwale zmienić deklaracje przechowywania krawędzi.

ArcadeDB (com.arcadedb:arcadedb-engine) do 26.8.1 zawiera niekompletną listę zabronioną w sandboxie skryptów polyglot: HostClassLookupFilter.DENIED wymienia java.util.ResourceBundle jako nazwę klasy, co nie obejmuje podklas, a ScriptTriggerExecutor.ALLOWED_PACKAGES zezwala na java.util.*. Użytkownik z uprawnieniem UPDATE_SCHEMA może odwołać się do java.util.PropertyResourceBundle lub java.util.ListResourceBundle i wywołać ResourceBundle.getBundle(String), aby odczytać zasoby .properties ze ścieżki klas aplikacji, ujawniając poufne dane konfiguracyjne. Naprawiono w 26.9.1.

ArcadeDB w wersjach przed 26.9.1 nie waliduje adresów przejściowych IPv6 w zabezpieczeniu SSRF używanym przez IMPORT DATABASE i polecenia serwera. Uwierzytelnieni atakujący mogą dostarczyć adresy URL rozwiązujące się do adresów NAT64, 6to4 lub Teredo zawierających wewnętrzne adresy IPv4 (RFC 1918 lub loopback), aby uzyskać dostęp do usług wewnętrznych i punktów końcowych metadanych chmury.

Podatność w ArcadeDB przed wersją 26.9.1 pozwala uwierzytelnionemu użytkownikowi o niskich uprawnieniach na obejście kontroli dostępu ACL na poziomie typów wierzchołków i krawędzi. Dzieje się to przez wysłanie żądania wsadowego do punktu końcowego POST /api/v1/batch/{database} z domyślnym równoległym przetwarzaniem, które nie wiąże tożsamości użytkownika z wątkami roboczymi. W efekcie użytkownik może zapisywać krawędzie do chronionych wierzchołków, modyfikując dane grafu bez autoryzacji.

Podatność w ArcadeDB przed wersją 26.9.1 dotyczy narzędzia query_database udostępnianego w interfejsie czatu AI. Narzędzie wykonuje zapytania bez powiązania uwierzytelnionego użytkownika z kontekstem bazy danych, co zamyka kontrolę dostępu na poziomie typów i zasobników. Uwierzytelnieni użytkownicy mogą odczytywać dane, do których dostęp jest jawnie zabroniony na poziomie typów.

ArcadeDB przed 26.9.1 nie egzekwuje wpisów ACL dla typów TimeSeries, ponieważ resolver ACL buduje uprawnienia na podstawie identyfikatorów bucketów, a typy TimeSeries nie posiadają normalnych bucketów rekordów. Uwierzytelniony użytkownik o niskich uprawnieniach może czytać lub wstawiać próbki TimeSeries pomimo jawnych reguł odmowy, wykorzystując brak sprawdzania dostępu opartego na nazwie typu, co powoduje, że wyszukiwanie uprawnień kończy się niepowodzeniem otwartym.

ArcadeDB przed wersją 26.7.1 pozwala użytkownikowi z rolą czytelnika na wysłanie POST /api/v1/command/{database} z language: js, ponieważ PolyglotQueryEngine.command, analyze i registerFunctions nie egzekwują autoryzacji administratora bazy danych. GraalPolyglotEngine pozwala również obejść whitelistę allowedPackages poprzez odbicie z obiektu bazy danych do dowolnych klas hosta.

W ArcadeDB przed wersją 26.6.1 instrukcja IMPORT DATABASE nie wymagała uprawnień administracyjnych i przekazywała źródło do modułu importu bez walidacji. Uwierzytelniony użytkownik z dostępem do poleceń SQL przez /api/v1/command lub /api/v1/query może podać adresy HTTP/HTTPS, aby wykonać żądania do usług wewnętrznych, lub ścieżki file://, aby odczytać pliki dostępne dla procesu serwera i zaimportować je jako rekordy. Importer XML umożliwia też przetwarzanie DTD i encji zewnętrznych.

W ArcadeDB przed wersją 26.6.1 poprawka CVE-2026-44221 dodała sprawdzenie uprawnień UPDATE_SCHEMA tylko do metody LocalDocumentType.createProperty, pozostawiając pozostałe publiczne mutatory schematu w LocalDocumentType.java i LocalProperty.java bez kontroli. Uwierzytelniona tożsamość, w tym token API tylko do odczytu bez uprawnienia UPDATE_SCHEMA, może przez punkty końcowe HTTP użyć DROP PROPERTY, ALTER TYPE lub ALTER PROPERTY, aby zmieniać nazwy typów, dziedziczenie, aliasy, koszyki, usuwać właściwości i zmieniać ograniczenia właściwości.

ArcadeDB przed wersją 26.8.1 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w implementacji OpenCypher LOAD CSV, która nie waliduje adresów URL HTTP/HTTPS. Uwierzytelnieni atakujący mogą tworzyć zapytania LOAD CSV wskazujące na wewnętrzne adresy sieciowe lub punkty końcowe metadanych chmury, aby zmusić serwer ArcadeDB do pobrania i zwrócenia wrażliwych danych z ograniczonych usług.

ArcadeDB przed wersją 26.8.1 zawiera podatność zdalnego wykonania kodu w silniku zapytań Gremlin. Mimo że domyślnie używany jest bezpieczny silnik java, ArcadeGremlin.executeStatement() po cichu przełącza się na niebezpieczny silnik Groovy, gdy żądanie zawiera parametry zapytania, a zapytanie nie jest parsowane jako gremlin-lang. Uwierzytelniony użytkownik z dowolną rolą, w tym tylko do odczytu, może wykonać dowolne polecenia systemu operacyjnego jako proces serwera ArcadeDB.

ArcadeDB (com.arcadedb) w wersjach 26.7.3 i wcześniejszych nie egzekwuje sprawdzenia uprawnień UPDATE_SCHEMA, gdy instrukcja DEFINE FUNCTION dotyczy już istniejącej biblioteki funkcji. Użytkownik z samym dostępem do bazy danych może dodawać lub nadpisywać funkcje SQL lub Cypher w istniejącej bibliotece i utrwalić zmianę, co umożliwia manipulowanie logiką funkcji zdefiniowanych przez administratora. Problem został naprawiony w wersji 26.8.1.

ArcadeDB przed wersją 26.8.1 nie sanityzuje nazw baz danych w poleceniach create database i drop database w punkcie końcowym POST /api/v1/server, co pozwala uwierzytelnionym użytkownikom root na zapisywanie i usuwanie dowolnych plików poza skonfigurowanym katalogiem baz danych. Atakujący mogą podać nazwy baz danych zawierające sekwencje ../, aby tworzyć bazy danych w dowolnych ścieżkach systemu plików lub rekurencyjnie usuwać katalogi, do których serwer ma dostęp.

Wtyczka Gremlin wire-protocol w ArcadeDB (com.arcadedb:arcadedb-gremlin) w wersjach <= 26.7.3 wymusza uwierzytelnianie (SASL PLAIN), ale nie przeprowadza autoryzacji: nie sprawdza uprawnień dostępu do bazy danych (canAccessToDatabase) i nie wiąże uwierzytelnionego podmiotu z silnikiem. W rezultacie każdy ważny poświadczenie serwera — nawet takie przyznane dla zero lub jednej niepowiązanej bazy — może czytać, zapisywać i usuwać dane w dowolnej bazie na serwerze, wybierając docelową bazę przez alias źródła przejścia, całkowicie omijając ACL silnika per-type/read-only/UPDATE_SCHEMA. Problem naprawiono w wersji 26.8.1.

ArcadeDB przed wersją 26.8.1 nie wiąże uwierzytelnionego podmiotu (setCurrentUser) w swoich handlerach HTTP dla operacji wsadowych i szeregów czasowych. Ponieważ żaden podmiot nie jest powiązany z wątkiem roboczym, warstwa ACL (LocalBucket.checkPermissionsOnFile) nie wykonuje się dla tych handlerów. Wdrożenia używające ACL per typ lub per grupa mogą pozwolić użytkownikowi z dostępem do bazy, ale ograniczonymi uprawnieniami per typ, na odczyt i zapis do typów, do których nie ma autoryzacji, poprzez wysyłanie żądań do endpointów wsadowych/szeregów czasowych. Wdrożenia opierające się wyłącznie na kontroli dostępu na poziomie bazy danych nie są dotknięte.

ArcadeDB przed wersją 26.8.1 (dotknięte wersje <= 26.7.3) zawiera brak autoryzacji w instrukcji SQL DELETE FUNCTION. DeleteFunctionStatement.executeSimple wyrejestrowuje i trwale usuwa funkcję serwerową bez żadnego sprawdzenia checkPermissionsOnDatabase (UPDATE_SCHEMA). Każdy użytkownik z dostępem do bazy danych może wykonać DELETE FUNCTION przez API poleceń (POST /api/v1/command/{db}), aby trwale usunąć dowolną zarejestrowaną funkcję serwerową, w tym logikę istotną dla bezpieczeństwa, wpływając na integralność i dostępność.

ArcadeDB w wersjach od 26.4.2 do 26.7.3 zawiera podatność na obejście autoryzacji w narzędziu set_server_setting na poziomie serwera MCP. SetServerSettingTool.execute() sprawdza tylko globalną flagę allowAdmin i nigdy nie sprawdza roli wywołującego, więc we wdrożeniu MCP z allowAdmin=true i nie-rootowym zestawem allowedUsers, każdy uwierzytelniony użytkownik tylko do odczytu może wywołać set_server_setting, aby zmodyfikować GlobalConfiguration serwera, umożliwiając manipulację konfiguracją lub odmowę usługi. Problem naprawiono w wersji 26.8.1.

ArcadeDB przed wersją 26.8.1 zawiera podatność na fałszowanie żądań po stronie serwera w poleceniu IMPORT DATABASE, gdzie walidator bezpieczeństwa rozwiązuje i sprawdza nazwy hostów, ale późniejsze połączenie ponownie rozwiązuje surowy URL i podąża za przekierowaniami. Uwierzytelnieni atakujący mogą ominąć walidator za pomocą ponownego wiązania DNS lub przekierowań HTTP, aby uzyskać dostęp do punktów końcowych metadanych chmury, usług wewnętrznych lub czytać dowolne pliki lokalne w domyślnych instalacjach.

ArcadeDB przed wersją 26.8.1 zawiera podatność na dowolny odczyt plików w klauzuli OpenCypher LOAD CSV FROM, która pozwala uwierzytelnionym użytkownikom na odczyt lokalnych plików. Atakujący z uprawnieniami do zapytań odczytu mogą użyć protokołu file:// w instrukcjach LOAD CSV, aby uzyskać dostęp do dowolnych plików z uprawnieniami procesu serwera, eksfiltrując wrażliwe dane bezpośrednio w odpowiedziach na zapytania.

ArcadeDB przed wersją 26.8.1 zawiera podatność na odmowę usługi w funkcji Cypher range(), która pozwala uwierzytelnionym użytkownikom wyczerpać pamięć sterty serwera. Atakujący mogą wysyłać zbyt duże wyrażenia range() z dużymi granicami, aby wywołać OutOfMemoryError i spowodować tymczasową degradację usługi lub jej niedostępność.

ArcadeDB przed wersją 26.8.1 zawiera podatność na dowolny odczyt plików w egzekwowaniu listy dozwolonych piaskownicy JavaScript GraalVM, która używa nieuciekających wyrażeń regularnych do walidacji nazw pakietów. Atakujący z uprawnieniami do tworzenia wyzwalaczy mogą użyć Java.type(), aby uzyskać dostęp do klas java.util.zip.ZipFile lub java.util.jar.JarFile i czytać dowolne pliki na systemie jako proces serwera ArcadeDB.

ArcadeDB (com.arcadedb:arcadedb-server) w wersjach do 26.7.3 zawiera podatność IDOR w punktach końcowych Raft cluster-info (GetClusterHandler i PostBootstrapStateHandler), które uwierzytelniają, ale nie autoryzują dostępu. W klastrze HA ArcadeDB (dostępnym tylko przy włączonym arcadedb.ha.enabled i załadowanym module ha-raft), każdy uwierzytelniony użytkownik — nawet z dostępem tylko do jednej bazy lub żadnej — może wyliczyć pełny rejestr baz serwera i uzyskać metadane per-baza, takie jak nazwy baz, ostatnie ID transakcji, odciski palców bootstrap i topologię klastra peer/leader, co prowadzi do ujawnienia informacji między bazami. Naprawiono w wersji 26.8.1.

ArcadeDB przed wersją 26.7.3 nie wiąże uwierzytelnionego principal w transporcie MCP HTTP, powodując, że wszystkie sprawdzenia uprawnień silnika są pomijane. Użytkownicy z dostępem MCP mogą wykonywać dowolne operacje zapisu, DDL, mutacje schematu i kod JavaScript.

ArcadeDB przed wersją 26.7.3 ujawnia token klastra (arcadedb.ha.clusterToken) w postaci jawnego tekstu przez narzędzie MCP get_server_settings. Atakujący z dostępem MCP może go wykorzystać do podszycia się pod roota.

ArcadeDB przed wersją 26.7.3 wiąże rzeczywisty obiekt LocalDatabase w kontekstach triggerów JavaScript z HostAccess.ALL, umożliwiając administratorom schematu wywołanie getSecurity().createUser() bez sprawdzania uprawnień.

ArcadeDB przed wersją 26.7.2 nie egzekwuje uprawnienia UPDATE_SCHEMA dla operacji SQL ALTER TYPE ... CUSTOM i ALTER TYPE ... BUCKETSELECTIONSTRATEGY. Uwierzytelniony użytkownik z dostępem tylko do odczytu może wysłać te instrukcje przez endpoint HTTP, aby zmutować metadane schematu i strategię wyboru segmentów, omijając granicę uprawnień updateSchema.

ArcadeDB przed wersją 26.7.2 nie zaciemnia tokena klastra w odpowiedzi GET /api/v1/server, umożliwiając uwierzytelnionym użytkownikom odczytanie arcadedb.ha.clusterToken w postaci jawnego tekstu. Atakujący mogą użyć wyciekłego tokena z nagłówkami X-ArcadeDB-Cluster-Token i X-ArcadeDB-Forwarded-User do podszycia się pod roota i wykonania działań administracyjnych, w tym tworzenia użytkowników, operacji na bazie danych i wyłączenia serwera.

ArcadeDB przed wersją 26.7.2 (arcadedb-engine) umożliwia skryptom wyzwalaczy odwoływanie się do klas hosta w java.lang.* (poprzez Java.type), ponieważ ScriptTriggerExecutor dodaje java.lang.* do dozwolonych pakietów. Uwierzytelniony użytkownik z uprawnieniami UPDATE_SCHEMA może utworzyć wyzwalacz JavaScript, który wywołuje java.lang.Runtime.getRuntime().exec() (lub ProcessBuilder), osiągając wykonanie poleceń systemu operacyjnego po uruchomieniu wyzwalacza.