Katalog podatności CVE

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

DOMPurify przed wersją 3.4.13 zawiera podatność na cross-site scripting w sanityzacji IN_PLACE, gdzie haki usuwania elementów nie neutralizują odłączonych poddrzew. Atakujący mogą dostarczyć HTML z handlerami zdarzeń na elementach potomnych, które wykonują się po zakończeniu sanityzacji, mimo że zwrócony korzeń wygląda na czysty.

Grav przed wersją 2.0.14 nie zabezpiecza pola access w podstawowym blueprint grupy wymaganym ograniczeniem security@: admin.super. Delegowany operator admin.users może zapisać grupę z access[admin][super]=true, aby eskalować do super-admina, uzyskując możliwości planowania i ewaluacji Twig.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do stosu admin-next/API Grav) przed wersją 1.0.14 nie egzekwuje wymogu autoryzacji w MenubarController::executeAction(). Podczas gdy punkt końcowy GET /menubar/items poprawnie filtruje elementy paska menu przez userPassesAuthorize(), punkt końcowy POST /api/v1/menubar/actions/{plugin}/{action} sprawdza tylko podstawowe uprawnienie api.access i nigdy nie ocenia pola authorize, które wtyczka zarejestrowała dla tej akcji. Każdy uwierzytelniony wywołujący z api.access może zatem bezpośrednio wywołać uprzywilejowaną akcję paska menu, omijając zamierzoną autoryzację. Żadna wtyczka dołączona do rdzenia Grav nie rejestruje obecnie uprzywilejowanego handlera authorize, więc na standardowej instalacji wpływ jest utajony; wada dotyczy każdej wtyczki pierwszej lub trzeciej strony polegającej na udokumentowanej semantyce authorize.

Wtyczka Grav API (getgrav/grav-plugin-api) przed wersją 1.0.14 zawiera podatność braku autoryzacji w funkcji userPassesAuthorize() (AbstractApiController.php). Funkcja nie sprawdza zakresów klucza API żądania, opierając się zamiast tego na surowym flagu super-admina i uprawnieniach ACL. W rezultacie uwierzytelniony atakujący posiadający klucz API z ograniczonym zakresem, wybity na koncie z uprawnieniami administratora, może ominąć deklarowane ograniczenia zakresu i uzyskać dostęp do metadanych UI i definicji elementów (sidebar/menubar/widget items oraz users-list columns/row-actions/filter-tabs), które powinny być dla niego zabronione, co prowadzi do ujawnienia informacji.

Grav przed wersją 2.0.14 zawiera podatność na przechowywany cross-site scripting w funkcji Security::detectXss() (system/src/Grav/Common/Security.php). Wszystkie wzorce wykrywania XSS używają modyfikatora PCRE /u (UTF-8), więc pojedynczy nieprawidłowy bajt UTF-8 w treści strony powoduje, że preg_match() zwraca false dla każdego wzorca, po cichu omijając bramkę bezpieczeństwa XSS przy zapisie (Validation::checkSafety()). Uwierzytelniony atakujący z uprawnieniami do edycji stron (bez uprawnienia security.xss_whitelist) może przechowywać złośliwy JavaScript, który wykonuje się w przeglądarce odwiedzającego daną stronę.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do Grav 2.0 w stosie admin-next/API) przed wersją 1.0.14 zawiera słabość otwartego przekierowania w SsoController::sanitizeReturnTo(). Funkcja odrzuca dosłowny prefiks '//', ale nie uwzględnia normalizacji backslashy do slashy przez przeglądarki w specjalnych schematach (http/https), więc wartość returnTo taka jak '/\evil.com' przechodzi przez zabezpieczenie i jest później rozwiązywana przez przeglądarkę jako URL względny protokołu '//evil.com'. Po legalnym przepływie logowania OAuth, parametr returnTo dostarczony przez atakującego może przekierować uwierzytelnioną ofiarę na stronę kontrolowaną przez atakującego w celu phishingu po zalogowaniu. Pełna eksploitowalność po stronie przeglądarki zależy od handlera oauth-callback po stronie klienta w admin-next SPA i nie została niezależnie zweryfikowana przez reportera.

Wtyczka Grav API (getgrav/grav-plugin-api, dołączona do Grav 2.0) przed wersją 1.0.14 (naprawiona w 1.0.15) zawiera podatność braku autoryzacji w BlueprintPathResolver::resolveUserScope(). Metoda blokuje zakres users/<name> na surowym flagu super-admina ACL (access.api.super) zamiast weryfikować faktyczny zakres prezentowanego klucza API. Atakujący posiadający klucz API z zakresem tylko api.media.write, wybity na koncie super-admina, może ominąć kontrolę autoryzacji i, przez POST /blueprint-upload lub GET /blueprint-files, zapisać plik w zakresie innego użytkownika (w wspólnym katalogu user/accounts/, ograniczonym do rozszerzeń obrazów przez assertSafeExtension()) i przeglądać listę plików w tym zakresie, mimo że klucz nie ma uprawnień api.users.write.

Grav przed wersją 2.0.15 zawiera podatność na trwały cross-site scripting w renderowaniu mediów audio i wideo przez metodę sourceParsedownElement. Fragment URL mediów jest konkatenowany bez ucieczki do elementów źródłowych rawHtml, co pozwala atakującym na wstrzyknięcie dowolnego HTML i JavaScript, który wykonuje się w sesjach przeglądających.

grav-plugin-api (getgrav/grav-plugin-api) w wersjach >= 1.0.0-beta.10 i <= 1.0.14 zawiera podatność na przechodzenie po ścieżkach w metodzie PagesController::batchCopy(). Niekompletna poprawka dla GHSA-qjq4-jp55-4mx2 pozostawiła niesprawdzony parametr 'suffix' kontrolowany przez użytkownika (przez POST /api/v1/pages/batch). Uwierzytelniony użytkownik z uprawnieniem api.pages.write (poziom edytora, nie super-admin) może podać sekwencje przechodzenia po ścieżkach (np. /../../../) w parametrze suffix, aby uciec z zamierzonego katalogu user/pages/ i zapisać treść strony oraz media strony kontrolowane przez atakującego w dowolnych lokalizacjach systemu plików zapisywalnych przez proces serwera WWW. Podatność naprawiono w wersji 1.0.15.

Wtyczka grav-plugin-api przed wersją 1.0.15 nie waliduje zawartości Twig w punkcie końcowym translate(), co pozwala atakującym z uprawnieniami api.pages.write na utrwalanie stron z włączonym process.twig. Atakujący mogą przesłać spreparowane parametry header i content, aby wykonać ładunki wstrzyknięcia szablonów po stronie serwera, które są oceniane podczas renderowania.

Grav przed wersją 2.0.15 zawiera podatność na trwały cross-site scripting w funkcji detectXss(), gdzie niesparowane cudzysłowy w niecytowanych wartościach atrybutów omijają wykrywanie procedur obsługi zdarzeń. Uwierzytelnieni edytorzy mogą wstrzyknąć procedury obsługi zdarzeń, takie jak onerror=, które przechodzą walidację i wykonują się w przeglądarkach odwiedzających podczas renderowania treści strony.