Podatności Budibase

Budibase do wersji 3.41.0 zawiera podatność na SSRF w generowaniu tabel AI, ponieważ funkcja uploadUrl w packages/server/src/utilities/fileUtils.ts używa surowego node-fetch zamiast fetchWithBlacklist. Uwierzytelnieni użytkownicy z rolą builder mogą wysłać prompt do POST /api/ai/tables, który umieszcza wewnętrzny URL w kolumnie załącznika, powodując, że serwer go pobiera i zwraca presigned URL do obiektu zawierający odpowiedź, np. dane uwierzytelniające z metadanych chmury.

Budibase to otwartoźródłowa platforma low-code, która przed wersją 3.39.0 miała luki w zabezpieczeniach związane z dostępem do tras GET i PUT dla pojedynczego źródła danych. Użytkownicy z rolą Basic mogli uzyskać dostęp do poufnych informacji, takich jak sekrety autoryzacji, poprzez manipulację danymi konfiguracyjnymi.

Budibase to otwartoźródłowa platforma low-code, która przed wersją 3.38.3 nie maskowała poprawnie wrażliwych danych w integracji z Snowflake. Użytkownik z autoryzacją BASIC mógł uzyskać pełny klucz PEM w formacie tekstowym.

Budibase to otwartoźródłowa platforma low-code. W wersjach przed 3.38.2, punkt końcowy przesyłania plików POST /api/attachments/process nie egzekwuje ograniczeń dotyczących aktywnej zawartości dla uwierzytelnionych użytkowników, co pozwala na przesyłanie niebezpiecznych plików przez uwierzytelnionych budowniczych.

Budibase przed wersją 3.38.1 ma lukę w REST API, która pozwala uwierzytelnionym użytkownikom aplikacji na modyfikację konfiguracji źródła danych. Użytkownicy z rolą BASIC lub wyższą mogą wysyłać żądania PUT do zmiany ustawień, co może prowadzić do nieautoryzowanego dostępu do wrażliwych danych.

Budibase to platforma open-source low-code, która przed wersją 3.38.1 miała lukę w zabezpieczeniach w punkcie końcowym POST /api/global/users/onboard. Umożliwia to użytkownikom z uprawnieniami budowniczego dostęp do tworzenia nowych kont globalnych administratorów, co prowadzi do eskalacji uprawnień.

Budibase to platforma open-source do niskokodowego tworzenia aplikacji. W wersjach przed 3.34.8 funkcja processUrlFile w pliku extract.ts nie weryfikowała adresów IP, co umożliwiało uwierzytelnionym użytkownikom wysyłanie żądań do wewnętrznych adresów sieciowych.

Budibase przed wersją 3.41.3 zawiera podatność na zdalne wykonanie kodu w obsłudze wtyczek, która pozwala uwierzytelnionym administratorom wykonać dowolny kod poprzez przesłanie złośliwego pakietu wtyczki. Serwer wywołuje eval() na plikach JavaScript wtyczki bez sandboxa w głównym procesie Node.js, umożliwiając atakującym kradzież zmiennych środowiskowych i poświadczeń z uprawnieniami roota w domyślnych instalacjach.

Budibase przed wersją 3.39.30 ma podatność w przepływie OIDC, gdzie adres e-mail nie jest weryfikowany pod kątem email_verified, a konta są łączone na podstawie adresu e-mail. Atakujący, który może uwierzytelnić się przez dostawcę tożsamości z niezweryfikowanym adresem e-mail ofiary, może przejąć konto ofiary i odziedziczyć jej role.

Budibase przed wersją 3.40.0 zawiera nieuwierzytelnioną podatność na wstrzykiwanie SQL w automatyzacjach wyzwalanych webhookiem z krokami EXECUTE_QUERY. Atakujący może wysłać JSON do endpointu webhooka, aby wstrzyknąć ładunki SQL wykonujące się z poświadczeniami bazy danych skonfigurowanymi przez buildera, umożliwiając eksfiltrację, modyfikację i trwałość danych w połączonych źródłach danych.

Budibase przed wersją 3.40.0 nieprawidłowo sanityzuje klucze obiektów S3, umożliwiając uwierzytelnionym builderom przesyłanie plików z sekwencjami traversal, które są zachowywane podczas eksportu. Atakujący mogą tworzyć nazwy plików zawierające segmenty .., które wychodzą poza katalog tymczasowy podczas eksportu obszaru roboczego, zapisując dowolną treść w dowolnej ścieżce zapisywalnej przez proces Budibase.

Budibase przed wersją 3.40.1 nie weryfikował, czy docelowy adres żądania odpowiada źródłu danych, przez co nieuwierzytelniony użytkownik mógł wysłać zapytanie do publicznego punktu końcowego i przechwycić zapisane poświadczenia (bearer, basic lub statyczne nagłówki). Problem został naprawiony w wersji 3.40.1.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.40.0 komponent integracji MySQL w Budibase jest skonfigurowany z multipleStatements: true, co umożliwia wykonanie wielu instrukcji SQL w jednym zapytaniu. Atakujący mogą wstrzykiwać złośliwe polecenia SQL przez pola wprowadzania danych użytkownika, co prowadzi do całkowitej kompromitacji bazy danych. Podatność została naprawiona w wersji 3.40.0.

Budibase przed wersją 3.39.9 zawiera podatność polegającą na nieprawidłowej walidacji dowiązań symbolicznych podczas przetwarzania plików ZIP. Atakujący na poziomie builder może wstrzyknąć dowiązanie symboliczne wskazujące na dowolny plik w systemie, który zostanie odczytany i przesłany do MinIO, a następnie udostępniony przez API.

Budibase przed wersją 3.39.12 zawiera podatność, która pozwala nieuwierzytelnionemu użytkownikowi na odczytanie wszystkich dokumentów z kolekcji MongoDB, CouchDB, Elasticsearch, DynamoDB-PartiQL lub REST-with-JSON-body, a w przypadku publicznych zapytań typu write również na modyfikację wszystkich dokumentów za pomocą jednego żądania HTTP. Problem wynika z nieprawidłowego walidowania danych wejściowych w funkcji validateQueryInputs, która odrzuca tylko znaczniki Handlebars, ale nie escapuje metaznaków JSON, co umożliwia wstrzyknięcie dodatkowych pól do obiektu filtra.

Budibase przed wersją 3.39.0 zawiera podatność, która pozwala anonimowemu atakującemu na uzyskanie podpisanej URL do zapisu do dowolnego zasobnika S3, do którego ofiara ma dostęp. Atak wymaga znajomości identyfikatora przestrzeni roboczej i źródła danych S3, ale nie wymaga uwierzytelnienia.

Budibase to platforma niskokodowa, która przed wersją 3.39.0 miała lukę w zabezpieczeniach w punkcie końcowym /api/public/v1/roles/assign. Umożliwia ona użytkownikom z rolą budowniczego podniesienie swoich uprawnień do globalnego administratora, co prowadzi do eskalacji uprawnień w całym środowisku najemcy.

Budibase przed wersją 3.33.4 umożliwia nieuwierzytelnionemu atakującemu zdalne wykonanie kodu (RCE) na serwerze poprzez wyzwolenie automatyzacji zawierającej krok Bash za pomocą publicznego endpointu webhook. Proces wykonuje się jako root w kontenerze.

Budibase przed wersją 3.33.4 zawiera podatność na fałszowanie żądań po stronie serwera (SSRF) w łączniku danych REST. Mechanizm ochrony SSRF (czarna lista IP) jest nieskuteczny, ponieważ zmienna środowiskowa BLACKLIST_IPS nie jest domyślnie ustawiona w żadnej oficjalnej konfiguracji wdrożeniowej. Gdy zmienna jest pusta, funkcja czarnej listy bezwarunkowo zwraca false, przepuszczając wszystkie żądania.

Budibase server przed wersją 3.45.0 zawiera podatność cross-tenant information disclosure w endpoincie GET /api/applications/:appId/appPackage, która pozwala uwierzytelnionym użytkownikom odczytać metadane aplikacji i kod źródłowy innego tenanta. Atakujący może podać identyfikator aplikacji ofiary, aby bez kontroli autoryzacji uzyskać wrażliwe szczegóły aplikacji, w tym strukturę nawigacji, nazwy ról, wewnętrzne adresy URL ekranów, fragmenty JavaScript i identyfikatory użytkowników.

Budibase Server przed wersją 3.45.0 nie redaguje jawnych poświadczeń źródeł danych przed rozgłaszaniem aktualizacji tabel zewnętrznych do pokoju websocket współpracy Builder. Atakujący z dostępem do Builder mogą przechwycić nieocenzurowane obiekty źródeł danych zawierające hasła do baz danych i klucze API, obserwując operacje zapisu lub usunięcia tabeli.

Budibase w wersjach przed 3.45.0 nie weryfikuje autoryzacji na poziomie aplikacji w punkcie końcowym POST /api/global/groups/:groupId/apps, umożliwiając builderom przypisywanie ról aplikacji poza granicami obszaru roboczego. Builder jednego obszaru roboczego może wykorzystać brak sprawdzania autoryzacji na poziomie aplikacji, aby przyznać sobie role administratora w innych obszarach roboczych poprzez modyfikację mapowań ról grup użytkowników.

Budibase przed wersją 3.45.0 nieprawidłowo ogranicza zakres endpointu GET /api/chat-links do workspace'u, co pozwala builderom wyliczać rekordy powiązań tożsamości czatu we wszystkich workspace'ach w tenancie. Atakujący z dostępem builder do jednego workspace'u może odczytać wrażliwe dane powiązań tożsamości czatu, w tym identyfikatory użytkowników i zewnętrzne identyfikatory usług czatu z innych workspace'ów, do których nie ma uprawnień.

Budibase w wersjach od 3.41.0 do 3.45.0 zawiera obejście uwierzytelniania w ścieżce logowania OIDC/SSO w @budibase/server. Gdy żaden istniejący użytkownik nie pasuje do przychodzącego podmiotu SSO, serwer wyszukuje oczekujące zaproszenia użytkowników wyłącznie po adresie e-mail potwierdzonym przez IdP — bez weryfikacji kodu zaproszenia i bez sprawdzenia email_verified. Atakujący mogący zarejestrować się w zaufanym IdP i podać zaproszony adres e-mail ofiary przejmuje oczekujące zaproszenie i dziedziczy wszystkie przyznane uprawnienia, w tym builder i admin.global.

Budibase (@budibase/server) przed wersją 3.45.0 buduje DDL zmiany nazwy kolumn MySQL i MSSQL w packages/backend-core/src/sql/sqlTable.ts, interpolując identyfikatory bezpośrednio do surowego zapytania bez użycia helperów quoteMySqlIdentifier / quoteSqlServerIdentifier. Atakujący z uprawnieniami DDL na podłączonym źródle danych MySQL/MSSQL może utworzyć kolumnę zawierającą backtick lub apostrof oraz dodatkowy SQL; gdy builder zmieni nazwę tej kolumny przez UI, wstrzyknięty SQL zostanie wykonany.

Budibase Server przed wersją 3.45.0 zawiera podatność na dowolny zapis plików w endpointcie przesyłania ikon PWA, który rozpakowuje dostarczone przez użytkownika archiwa ZIP bez odpowiedniej walidacji dowiązań symbolicznych. Atakujący z rolą BUILDER może stworzyć złośliwy ZIP z dowiązaniami symbolicznymi i zduplikowanymi wpisami plików, aby zapisać dowolne pliki jako root.

Budibase przed wersją 3.45.0 zawiera nieuwierzytelnioną podatność server-side request forgery i eksfiltracji poświadczeń w endpoincie webhook Microsoft Teams, który przyjmuje sfałszowane aktywności Bot Framework z dowolnymi wartościami serviceUrl. Atakujący może wysłać spreparowane żądanie POST, aby wstrzyknąć kontrolowany przez siebie serviceUrl, który jest utrwalany i używany do wszystkich kolejnych odpowiedzi bota, powodując wysyłanie aktywnych tokenów dostępu Microsoft OAuth w nagłówkach Authorization do hosta atakującego oraz umożliwiając ślepy dostęp do sieci wewnętrznej.

Budibase w wersjach przed 3.45.0 nie wyłącza rozwiązywania zewnętrznych referencji JSON w walidatorze importu OpenAPI/Swagger, co pozwala uwierzytelnionym builderom odczytywać dowolne pliki lokalne. Atakujący z dostępem builder może osadzić referencje file:// w specyfikacjach OpenAPI przesyłanych do endpointu importu, aby eksfiltrować wrażliwe pliki, w tym zmienne środowiskowe zawierające sekrety JWT, klucze API i poświadczenia baz danych.

Budibase przed wersją 3.41.3 nie egzekwuje autoryzacji opartej na rolach na punktach końcowych zarządzania licencjami, co pozwala każdemu uwierzytelnionemu użytkownikowi na usuwanie kluczy licencyjnych lub manipulowanie tokenami offline. Atakujący z podstawowymi uprawnieniami użytkownika mogą uzyskać dostęp do /api/global/license/*, aby wyłączyć funkcje premium i zdegradować wdrożenia dla wszystkich użytkowników.

Budibase przed wersją 3.41.3 zawiera podatność braku autoryzacji w punkcie końcowym POST /api/resources/duplicate, która pozwala uwierzytelnionym builderom wstrzykiwać tabele, automatyzacje, zapytania i ekrany do dowolnej innej aplikacji bez posiadania roli w docelowym workspace. Atakujący mogą wstrzykiwać zasoby, podając dowolny identyfikator docelowego workspace w treści żądania, a następnie uruchamiać wstrzyknięte automatyzacje z wychodzącymi webhookami, aby eksfiltrować dane z aplikacji ofiary.

Budibase przed wersją 3.41.3 nie waliduje przypisań ról buildera w zakresie aplikacji w publicznych punktach końcowych tworzenia i aktualizacji użytkowników, co pozwala uwierzytelnionemu builderowi w zakresie aplikacji przyznać dostęp buildera do niepowiązanych aplikacji. Atakujący mogą wysyłać spreparowane żądania do API aktualizacji użytkownika z polami builder.apps, aby eskalować uprawnienia i uzyskać nieautoryzowany dostęp buildera do innych aplikacji w tym samym tenant.

Budibase przed wersją 3.41.3 nie egzekwuje ograniczeń ról per tabela na punkcie końcowym POST /api/datasources/query, co pozwala użytkownikom z niskimi uprawnieniami BASIC odczytywać, tworzyć, aktualizować lub usuwać wiersze w dowolnej tabeli niezależnie od skonfigurowanych uprawnień. Atakujący z rolą BASIC mogą wysyłać spreparowane żądania zapytań z identyfikatorami docelowych tabel, aby ominąć kontrolę dostępu na poziomie tabel i manipulować ograniczonymi danymi.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.40.0, w packages/backend-core/src/utils/outboundFetch.ts przypinano zweryfikowany adres przez agenta Node, ale integracja REST używała getDispatcher z packages/backend-core/src/utils/fetch.ts, co powodowało, że undici ignorował tego agenta i ponownie rozwiązywał nazwę hosta. Konstruktor mógł użyć DNS rebinding, aby sprawić, że packages/server/src/integrations/rest.ts połączy się z wewnętrznym adresem po tym, jak publiczny adres przeszedł walidację, z pełnym dostępem do odpowiedzi i dowolnymi metodami REST. Poprawka dodaje obsługę createPinnedLookup do dyspozytora undici i przekazuje zweryfikowany adres do niestandardowych implementacji fetch. Problem został naprawiony w wersji 3.40.0.

Budibase przed wersją 3.39.19 zawiera podatność w łączniku PostgreSQL, gdzie pole konfiguracyjne schema jest interpolowane do instrukcji SET search_path bez odpowiedniego escapowania podwójnych cudzysłowów. Uwierzytelniony administrator może wykonać dowolny kod SQL.

Budibase przed wersją 3.41.3 zawiera podatność w punkcie końcowym POST /api/attachments/:datasourceId/url, gdzie uwierzytelniony użytkownik opublikowanej aplikacji z rolą BASIC może podać kontrolowane wartości bucket i key, uzyskując podpisane adresy URL oparte na zapisanych poświadczeniach S3.

Budibase przed wersją 3.41.3 zawiera podatność w krokach automatyzacji (outgoingWebhook, zapier, n8n, slack, discord), gdzie używają one node-fetch na adresach URL dostarczonych przez użytkownika bez egzekwowania BLACKLIST_IPS, co pozwala uwierzytelnionemu użytkownikowi na wykonywanie żądań po stronie serwera do metadanych chmury i wewnętrznych usług.

Budibase w wersjach od 3.39.4 do 3.40.0 zawiera regresję autoryzacji w punkcie końcowym przesyłania załączników S3, która pozwala użytkownikom BASIC na uzyskanie podpisanych URL-i S3 PutObject poprzez wysyłanie żądań POST do punktu końcowego załączników. Trasa została zmieniona z kontroli uprawnień BUILDER na kontrolę TABLE/WRITE, którą użytkownicy BASIC mają domyślnie. Atakujący mogą określić dowolne zasobniki S3 w treści żądania, aby wygenerować podpisane URL-e do zapisu w dowolnym zasobniku dostępnym dla przechowywanych poświadczeń IAM, co umożliwia nieautoryzowane przesyłanie plików.

Budibase przed wersją 3.39.18 zawiera podatność na wstrzyknięcie SQL w integracji MySQL, gdzie nazwa tabeli nie jest poprawnie escapowana w zapytaniu DESCRIBE. Atakujący może utworzyć tabelę z nazwą zawierającą backtick i dodatkowe zapytanie, które zostanie wykonane podczas skanowania schematu przez administratora. Problem naprawiono w wersji 3.39.18.

Budibase przed wersją 3.39.24 zawiera podatność w punkcie końcowym POST /api/public/v1/roles/assign, gdzie brakuje walidacji appBuilder.appId lub role.appId. Użytkownik z uprawnieniami buildera w jednej aplikacji może przypisać sobie uprawnienia buildera lub dowolną rolę w innej aplikacji, uzyskując dostęp do jej danych, konfiguracji źródeł danych i automatyzacji. Problem naprawiono w wersji 3.39.24.

Budibase przed wersją 3.39.25 ma podatność w endpointach GET /api/users/metadata i GET /api/users/metadata/:id. Odpowiedzi zawierają obiekty użytkowników bez usunięcia pól oauth2.accessToken i oauth2.refreshToken. Użytkownik z rolą POWER może pobrać dane uwierzytelniające dostawcy tożsamości użytkowników SSO i użyć tokenów odświeżania do trwałego dostępu do połączonych usług.

Budibase przed wersją 3.40.0 nie maskuje poświadczeń źródeł danych przechowywanych w polach typu STRING, co pozwala uwierzytelnionym użytkownikom na odczytanie w postaci jawnej ciągów połączeń MongoDB i kluczy prywatnych Firebase. Atakujący z uprawnieniami odczytu tabel mogą pobrać konfiguracje źródeł danych przez API, uzyskując dostęp do poświadczeń baz danych i kluczy kont usług.

Budibase przed wersją 3.40.0 zawiera podatność w punkcie końcowym PUT /api/global/users/tenant/owner (changeTenantOwnerEmail), która pozwala każdemu uwierzytelnionemu użytkownikowi, nawet z najniższymi uprawnieniami BASIC, na zmianę adresu e-mail właściciela konta na adres kontrolowany przez atakującego. Atakujący może następnie użyć publicznego mechanizmu resetowania hasła, aby przejąć konto administratora, uzyskując pełny dostęp administracyjny.

Budibase przed wersją 3.40.0 zawiera podatności typu Server-Side Request Forgery (SSRF) w imporcie zapytań OpenAPI i wykonywaniu zapytań REST, które pozwalają uwierzytelnionym użytkownikom z uprawnieniami buildera na obejście ochrony DNS pinning poprzez ataki DNS rebinding. Atakujący mogą skonfigurować nazwy hostów, które podczas walidacji rozwiązują się na adresy publiczne, ale podczas rzeczywistego połączenia na adresy pętli zwrotnej lub prywatne, umożliwiając dostęp do zablokowanych wewnętrznych usług HTTP.

Budibase przed wersją 3.40.0 zawiera podatność na wstrzyknięcie SQL w łączniku Oracle, w wyszukiwaniu wierszy po zapisie, gdzie nazwy tabel nie są poprawnie escapowane. Atakujący z uprawnieniami zapisu na tabeli z cudzysłowem w nazwie może wstrzyknąć SQL, który wykona się jako użytkownik bazy danych, umożliwiając odczyt lub modyfikację dowolnych danych.

Budibase przed wersją 3.40.0 zawiera podatność na Cross-Site Request Forgery (CSRF) w punkcie końcowym handoff linku czatu, która pozwala atakującym na powiązanie zewnętrznej tożsamości czatu z kontem ofiary. Atakujący mogą stworzyć stronę phishingową, która automatycznie wysyła żądanie POST z przeciekiem tokena potwierdzającego, aby powiązać swoją tożsamość czatu z kontem ofiary, umożliwiając podszywanie się w operacjach agenta i dziedziczenie uprawnień ofiary.

Budibase przed wersją 3.40.0 zawiera podatność na wstrzyknięcie NoSQL w integracji z MongoDB, gdzie parametry dostarczone przez użytkownika są wzbogacane za pomocą handlebars z noEscaping: true i parsowane bez filtrowania operatorów. Atakujący mogą wstrzyknąć operatory MongoDB przez parametry zapytania, aby ominąć kontrolę dostępu per użytkownik, odczytać dowolne dokumenty, wykonać JavaScript przez operatory $where lub modyfikować kolekcje przez operacje update i delete.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.40.1, w packages/server/src/integrations/mongodb.ts przekazywano kontrolowane przez buildera wartości tlsCertificateKeyFile i tlsCAFile bezpośrednio do MongoClient w Budibase Cloud. Builder mógł przesłać bezwzględne ścieżki serwera przez /api/datasources/verify i odróżnić czytelne istniejące pliki od brakujących, porównując błąd sterownika, co ujawniało istnienie i czytelność plików na współdzielonym serwerze. Problem został naprawiony w wersji 3.40.1.

Budibase przed wersją 3.39.32 udostępnia endpoint GET /api/global/users/tenant/:id w PUBLIC_ENDPOINTS, a funkcja tenantUserLookup zwraca pełny dokument PlatformUser. Nieuwierzytelniony atakujący może sprawdzić istnienie użytkownika, uzyskać identyfikatory dzierżawy, identyfikatory użytkowników, adresy e-mail, identyfikatory SSO i metadane rewizji dokumentów.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.39.25, packages/server/src/api/controllers/automation.ts zwracał wyniki testów automatyzacji zawierające trigger.outputs.user.oauth2, broadcastował BuilderSocketEvent.AutomationTestProgress do pokoju aplikacji i przechowywał postęp w packages/server/src/automations/testProgress.ts bez zakresu użytkownika. Współbudowniczy mógł otrzymać lub odpytać test innego buildera uwierzytelnionego przez SSO i uzyskać tokeny dostępu i odświeżania OAuth2. Poprawka dodaje sanitizeAutomationTestResult i izoluje postęp według użytkownika. Problem został naprawiony w wersji 3.39.25.

Budibase to platforma low-code o otwartym kodzie źródłowym. Przed wersją 3.39.4, uploadUrl w packages/server/src/utilities/fileUtils.ts używał surowego fetch po stronie serwera dla wartości załączników przekazywanych przez processAttachments w packages/server/src/sdk/workspace/ai/helpers/rows.ts. Builder z funkcją generowania tabel AI mógł spowodować, że wartość załącznika odnosi się do wewnętrznej usługi lub punktu końcowego metadanych chmury, a odpowiedź byłaby przechowywana jako załącznik bez walidacji fetchWithBlacklist. Problem został naprawiony w wersji 3.39.4.