Podatności ArcadeDB

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.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.

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 (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.

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.