CVE-2026-109340

SurrealDB w wersjach od 3.0.0 do 3.3.0 zawiera lukę braku uwierzytelniania w metodzie RPC revoke, która pozwala użytkownikom o niskich uprawnieniach lub nieuwierzytelnionym wywołującym unieważniać tokeny odświeżania innych użytkowników bez dowodu posiadania. Atakujący mogą uzyskać identyfikatory grantów przez ACCESS SHOW ALL z uprawnieniem VIEWER lub wyciekłe tokeny, a następnie trwale unieważnić tokeny odświeżania, wymuszając ponowne uwierzytelnienie.

SurrealDB przed wersją 3.3.0 zawiera podatność obejścia autoryzacji, która pozwala wywołującym z uprawnieniami zapisu na poziomie tabeli na odczyt pól ograniczonych przez SELECT poprzez rozwiązywanie wskaźników JSON Patch względem niezredukowanego rekordu. Atakujący mogą użyć operacji PATCH copy lub move, aby skopiować ukryte pola do czytelnych miejsc, lub nadużyć błędów niezgodności testu jako wyroczni ujawniającej.

SurrealDB w wersjach przed 3.3.0 zawiera lukę obejścia autoryzacji, która pozwala użytkownikom rekordów wywnioskować wartości pól ukrytych przez uprawnienia SELECT na poziomie pola, używając predykatów LIVE SELECT WHERE na $before lub $after. Atakujący mogą tworzyć powtarzające się predykaty i obserwować, czy powiadomienia są dostarczane przy CREATE, UPDATE lub DELETE, aby potwierdzić lub zawęzić wartości zastrzeżonych pól.

SurrealDB w wersjach przed 3.3.0 zawiera lukę obejścia autoryzacji, która pozwala użytkownikom rekordów odczytywać pola ukryte przez uprawnienia SELECT na poziomie pola poprzez projekcje LIVE SELECT. Atakujący mogą projektować zastrzeżone pola z niezredukowanych parametrów $after lub $before pod aliasem, aby otrzymać dokładne przechowywane wartości w powiadomieniach CREATE, UPDATE i DELETE.

SurrealDB przed wersją 3.3.0 umożliwia dostęp między dzierżawcami, ponieważ instrukcja SurrealQL USE przełącza sesję na dowolną przestrzeń nazw/bazę danych bez sprawdzania, czy poziom uwierzytelnienia wywołującego go obejmuje. Uwierzytelnieni użytkownicy przestrzeni nazw, baz danych lub rekordów mogą przełączyć się na innego dzierżawcę i czytać, tworzyć, aktualizować lub usuwać wiersze w tabelach, których PERMISSIONS na to pozwalają, takich jak PERMISSIONS FULL.

SurrealDB w wersjach od 3.1.0 do 3.3.0 pozwala modułom Surrealism wyczerpać pamięć serwera, ponieważ linie stdout/stderr modułu są buforowane bez ograniczeń w pamięci hosta, omijając skonfigurowany limit pamięci modułu. Atakujący może uruchomić złośliwy moduł zainstalowany przez właściciela, który zapisuje dane wyjściowe bez znaków nowej linii, powodując awarię serwera i odmowę usługi dla wszystkich przestrzeni nazw i baz danych.

SurrealDB w wersjach przed 3.3.0 zawiera lukę odmowy usługi, która pozwala użytkownikom z możliwością wykonywania zapytań na awarię serwera poprzez odczytywanie nie-ASCII wartości nagłówków w osadzonym JavaScripcie. Atakujący z włączonym skryptowaniem może odczytać takie wartości przez Headers get(), entries(), values() lub getSetCookie(), albo zwrócić je z punktów końcowych fetch(), powodując przerwanie procesu serwera.

SurrealDB w wersjach od 3.0.0 do 3.3.0 zawiera lukę ujawnienia informacji, która pozwala użytkownikom rekordów odczytywać wartości ukryte przez uprawnienia SELECT na poziomie pola poprzez pola COMPUTED. Atakujący mogą wybierać rekordy, których czytelne pola COMPUTED pochodzą z ukrytych pól, lub używać klauzul RETURN przy zapisie z $before/$after, aby ujawnić ukryte wartości.

SurrealDB przed wersją 3.3.0 nie sprawdza wybranej przez wywołującego przestrzeni nazw lub bazy danych względem poziomu, na którym uwierzytelniony jest użytkownik systemowy na poziomie przestrzeni nazw lub bazy danych, co umożliwia dostęp między dzierżawcami. Uwierzytelniony atakujący może ustawić nagłówki Surreal-NS/Surreal-DB na /sql lub wywołać metodę RPC use, aby czytać, tworzyć, modyfikować i usuwać wiersze oraz odczytywać wartości DEFINE PARAM w innym dzierżawcy, jeśli PERMISSIONS tabel na to pozwalają.

SurrealDB w wersjach od 3.0.0 do 3.3.0 zawiera lukę obejścia autoryzacji, która pozwala uwierzytelnionym użytkownikom rekordów odczytywać rekordy w innych przestrzeniach nazw lub bazach danych poprzez rozwiązywanie identyfikatorów rekordów przez FETCH. Atakujący mogą przełączyć się na obcą przestrzeń nazw/bazę danych i podać znany identyfikator rekordu w zapytaniu RETURN … FETCH, aby odczytać dane innego dzierżawcy, gdy uprawnienia tabeli pozwalają na odczyt.