Podatności NocoDB

NocoDB w wersjach do 0.106.0 (lub 0.109.1) ma podatność na traversję ścieżki, która pozwala nieautoryzowanemu atakującemu na dostęp do dowolnych plików na serwerze poprzez manipulację parametrem ścieżki w trasie /download.

NocoDB przed wersją 2026.05.1 miał podatność, która pozwalała na wykorzystanie punktu końcowego importu arkuszy kalkulacyjnych axiosRequestMake jako ogólnego proxy HTTP. Punkt ten był dostępny bez uwierzytelnienia, co umożliwiało nieautoryzowany dostęp.

NocoDB przed wersją 2026.05.1 miał podatność w punkcie końcowym migracji bazowej, który akceptował URL dostarczony przez wywołującego bez wymuszania protokołu lub miejsca docelowego. To umożliwiało nadużycie schematu oraz badanie wewnętrznych adresów HTTP.

NocoDB przed wersją 2026.05.1 pozwalał na przesyłanie załączników .html lub .svg, które były renderowane w przeglądarce zamiast wymuszać pobranie. Problem wynikał z niezgodności w sposobie obsługi nagłówków odpowiedzi, co prowadziło do automatycznego renderowania tych plików.

NocoDB przed wersją 2026.05.1 miał podatność, w której skradziony token odświeżania mógł być użyty do generowania nowych JWT nawet po zresetowaniu hasła przez użytkownika. Proces zapomnienia hasła nie usuwał wszystkich tokenów odświeżania, co umożliwiało atakującemu wymianę skradzionego tokena na nowy token dostępu.

NocoDB przed wersją 2026.05.1 miał podatność w punkcie końcowym spreadsheet-fetch (axiosRequestMake), który akceptował URL-e z dozwoloną rozszerzeniem w dowolnym miejscu w ciągu. Umożliwiało to dostęp do punktu końcowego cloud-metadata za pomocą spreparowanego URL-a.

NocoDB przed wersją 2026.05.1 zawierał lukę w usłudze użytkowników, gdzie funkcja revokeAllOAuthTokensByUser była pustym stubem. W wyniku tego, tokeny OAuth nie były unieważniane po zmianie, zresetowaniu lub odzyskaniu hasła przez użytkownika.

Podatność w NocoDB przed wersją 2026.05.1 umożliwiała posiadaczowi tokena MCP o niskich uprawnieniach, znającemu ścieżkę do załącznika, odczyt dowolnego pliku w udostępnionym magazynie, w tym załączników należących do innych baz i obszarów roboczych. Problem wynikał z braku weryfikacji własności pliku przez narzędzie readAttachment.

NocoDB przed wersją 2026.05.1 miał podatność, która pozwalała na jednoczesne wykorzystanie tego samego kodu autoryzacji OAuth do wygenerowania dwóch różnych par tokenów (access_token, refresh_token). To naruszało zasadę jednorazowego użycia, na której opiera się PKCE.

NocoDB przed wersją 2026.05.1 pozwalał uwierzytelnionym użytkownikom z uprawnieniami do tworzenia baz na dołączenie źródła SQLite wskazującego na dowolny plik na hoście NocoDB, w tym wewnętrzne bazy danych NocoDB. Użytkownicy mogli wskazać plik noco.db lub inne bazy danych, co umożliwiało odczyt lub nadpisanie ich zawartości.

NocoDB przed wersją 2026.05.1 pozwala uwierzytelnionym użytkownikom z uprawnieniami do tworzenia kolumn na wstrzykiwanie SQL do punktu końcowego grupowania danych. Użytkownik może to osiągnąć, ustawiając tytuł kolumny na fragment SQL, co omija istniejącą listę dozwolonych kolumn.

NocoDB przed wersją 2026.05.1 pozwalał uwierzytelnionym komentatorom na przechowywanie HTML w komentarzach wierszy, co skutkowało wykonaniem skryptu podczas najeżdżania kursorem na komentarz w widoku rozszerzonym. Brak sanitizacji po stronie serwera umożliwiał wstrzykiwanie złośliwego kodu.

NocoDB przed wersją 2026.05.1 miał podatność, która pozwalała na otwarcie surowego gniazda TCP do hosta bazy danych dostarczonego przez użytkownika bez weryfikacji adresu docelowego. To umożliwiało dostęp do prywatnych i lokalnych adresów, w tym do localhost.

NocoDB przed wersją 2026.05.1 pozwalał użytkownikom w jednym obszarze roboczym na uzyskanie dostępu do integracji innego obszaru roboczego poprzez punkt końcowy testConnection, podając jego identyfikator. Problem wynikał z błędnej weryfikacji uprawnień, co umożliwiało nieautoryzowany dostęp.

NocoDB przed wersją 2026.04.1 miał problem z różnym czasem odpowiedzi podczas logowania w zależności od tego, czy adres e-mail był znany, czy nie. W przypadku nieznanego użytkownika odpowiedź była zwracana bez porównania hasła, co stwarzało lukę bezpieczeństwa.

NocoDB przed wersją 2026.05.1 miał problem z weryfikacją haseł w trybie shared-view, co prowadziło do wycieku długości hasła oraz prefiksu znakowego przez czas odpowiedzi. Ta podatność została naprawiona w wersji 2026.05.1.

NocoDB przed wersją 2026.04.1 miał podatność, która umożliwiała ujawnienie wartości z ukrytych kolumn w publicznych punktach widokowych. Użytkownicy mogli uzyskać dostęp do tych wartości poprzez różne ścieżki, takie jak grupowanie, filtrowanie i sortowanie.

NocoDB przed wersją 2026.04.1 zawierał podatność w wtyczce hashRedirect, która umożliwiała przekierowanie użytkowników na złośliwe strony. Przekierowanie następowało po sprawdzeniu, czy ścieżka zaczyna się od '/', co pozwalało na wykorzystanie URL-i względnych protokołu.

NocoDB przed wersją 2026.04.1 miał podatność w stronie resetowania hasła, która renderowała token URL bezpośrednio w literałach ciągów JavaScript. Odpowiednio skonstruowany token mógł przełamać kontekst ciągu JS i wykonać skrypt kontrolowany przez atakującego.

NocoDB przed wersją 2026.04.1 pozwala uwierzytelnionemu użytkownikowi z uprawnieniami columnAdd na wstrzykiwanie dowolnego SQL do silnika formuł poprzez argument direction funkcji ARRAYSORT(...). Wartość ta nie jest ograniczona przez walidację formuły i jest osadzana w klauzuli ORDER BY, co prowadzi do wykonania podczas tworzenia kolumny oraz przy każdym odczycie rekordu z kolumny formuły.

NocoDB przed wersją 2026.05.1 miał lukę, która pozwalała na dostęp do ukrytych kolumn w widokach współdzielonych. Endpointy relacji publicznych akceptowały identyfikator kolumny dostarczony przez użytkownika bez weryfikacji, czy kolumna była widoczna w danym widoku.

W oprogramowaniu NocoDB przed wersją 2026.04.4 usunięte tokeny API nadal umożliwiały uwierzytelnianie żądań do czasu wygaśnięcia wpisu w pamięci podręcznej. Podatność wynikała z faktu, że proces usuwania tokena nie unieważniał odpowiadającego mu wpisu w cache'u autoryzacyjnym, co tworzyło okno czasowe do 3 dni, w którym usunięty token pozostawał aktywny.

W NocoDB przed wersją 2026.04.1, funkcja przesyłania plików przez URL nie sprawdzała limitu rozmiaru pliku (NC_ATTACHMENT_FIELD_SIZE) ani dla deklarowanego nagłówka Content-Length zdalnego pliku, ani dla zdekodowanej długości URI danych. Umożliwiało to uwierzytelnionemu użytkownikowi ominięcie skonfigurowanego limitu rozmiaru pliku.

NocoDB przed wersją 2026.04.1 miał lukę, która pozwalała atakującym na uzyskanie dostępu do członków bazy danych poprzez UUID sesji współdzielonej. Atakujący mógł zapraszać dowolne adresy e-mail jako prawdziwych członków bazy, co prowadziło do nieautoryzowanego dostępu.

NocoDB przed wersją 2026.04.1 miało lukę w zabezpieczeniach dotyczącą ciasteczka refresh-token, które było ustawione z httpOnly: true, ale brakowało mu flagi secure oraz atrybutu sameSite. To umożliwiało przechwycenie ciasteczka w sieci oraz ataki CSRF na punkt końcowy odświeżania tokenów.

NocoDB przed wersją 2026.04.1 miał nieprawidłową ochronę przed SSRF w czterech wtyczkach webhooków powiadomień (Slack, Discord, Mattermost, Teams). Użytkownik z uprawnieniami do tworzenia hooków mógł kierować wychodzące żądania POST do dowolnych wewnętrznych hostów.

NocoDB przed wersją 2026.04.1 zawierał podatność na refleksyjny XSS w stronie ostrzegania przed opuszczeniem. Parametry zapytania ncRedirectUrl i ncBackUrl były używane w window.location.href oraz w powiązaniach tagów <a> bez walidacji, co umożliwiało wstrzykiwanie URI javascript:.