Katalog podatności CVE

SvelteKit przed wersją 2.69.1 nie waliduje poprawnie rozmiarów ładunków w zdalnych funkcjach formularzy, co pozwala atakującym na awarię procesu Node przez wysyłanie dużych ładunków. Wielokrotne wykorzystanie powoduje denial of service przez ciągłe awarie procesu aplikacji.

gitoxide w wersjach od 0.25.4 zawiera podatność na wyciek poświadczeń HTTP w backendzie transportowym opartym na curl, gdzie poświadczenia są wysyłane do serwerów kontrolowanych przez atakującego po przekierowaniach HTTP. Podatność występuje, ponieważ walidacja poświadczeń sprawdza oryginalny URL zamiast efektywnego URL po przekierowaniu, co pozwala atakującym na kradzież tokenów uwierzytelniających przez przekierowania między domenami lub degradację HTTPS do HTTP.

gitoxide przed wersją 0.69.0 zawiera niesprawdzane indeksowanie tablicy podczas aplikowania delt oraz nieograniczoną alokację pamięci na podstawie rozmiarów kontrolowanych przez atakującego w nagłówkach w gix-pack. Atakujący mogą wysłać spreparowane dane pakietu podczas klonowania lub pobierania, aby wywołać panikę lub zabicie procesu z powodu braku pamięci.

gitoxide (crates Rusta gix <= 0.72.0 i gix-validate <= 0.10.0) zawiera podatność na przechodzenie po ścieżkach. Funkcja walidacji nazw podmodułów w gix-validate sprawdza tylko pierwsze wystąpienie '..' przez name.find(b".."), co pozwala na obejście walidacji przez spreparowane nazwy takie jak 'a..b/../../../.git/'. Dodatkowo ta walidacja nie jest wywoływana w ścieżkach produkcyjnych. W połączeniu z wadą dziedziczenia zaufania w Submodule::open(), gdzie git_dir_trust (Trust::Full) repozytorium nadrzędnego jest klonowane i pomijana jest weryfikacja własności, atakujący może stworzyć złośliwy plik .gitmodules, aby narzędzie ofiary zbudowane na gitoxide czytało dowolną konfigurację repozytorium git (w tym osadzone poświadczenia) z pełnym zaufaniem, omijając ochronę safe-directory. Naprawione w gix 0.82.0 i gix-validate 0.11.1.

gitoxide przed wersją 0.52.1 podąża za dowiązaniami symbolicznymi podczas odczytu pliku .gitmodules w katalogu roboczym, co pozwala atakującym na wstrzyknięcie bajtów spoza repozytorium do metadanych podmodułów. Atakujący mogą stworzyć złośliwe repozytorium z dowiązaniem symbolicznym .gitmodules wskazującym poza drzewo repozytorium, powodując, że gitoxide parsuje dowolne zewnętrzne pliki jako konfigurację podmodułów i ujawnia kontrolowane przez atakującego wartości name, path i url.

gitoxide przed wersją 0.52.1 nie waliduje nazw podmodułów z konfiguracji .gitmodules, co pozwala na przechodzenie po ścieżkach podczas wyznaczania katalogów git podmodułów. Atakujący mogą stworzyć złośliwe nazwy podmodułów z segmentami przechodzenia, aby przekierować funkcje state() i open() do repozytoriów poza .git/modules, powodując zamieszanie repozytoriów i inspekcję repozytoriów kontrolowanych przez atakującego.

gitoxide gix-packetline przed wersją 0.21.5 zawiera podatność na panikę w implementacji TextRef, która występuje podczas przetwarzania pakietów side-band z pustymi ładunkami. Złośliwy serwer Git może wysłać spreparowany pakiet side-band, aby wywołać panikę z powodu indeksu poza zakresem, co powoduje przerwanie procesu klienta podczas operacji fetch bez uwierzytelnienia.

W gitoxide przed wersją 0.38.2 nie są poprawnie walidowane znaki powrotu karetki w wartościach URL przekazywanych do pomocników poświadczeń. Atakujący mogą dostarczyć URL zawierające gołe powroty karetki, aby wstrzyknąć dodatkowe pola protokołu pomocnika i spowodować, że pomocnicy zwrócą poświadczenia dla hostów wskazanych przez atakującego zamiast żądanego URL.

Podatność w gix-worktree-state przed wersją 0.33.0 (część gitoxide) umożliwia zapisywanie plików poza katalogiem roboczym w systemie Windows. Funkcja checkout() podąża za istniejącym terminalnym dowiązaniem symbolicznym podczas przyrostowej materializacji, co pozwala nadpisać pliki poza katalogiem roboczym.

Crate gix-url w gitoxide (<= 0.32.0, naprawione w 0.37.1) używa ręcznie napisanego parsera URL, który nie traktuje '?' ani '#' jako końca komponentu authority, wbrew RFC 3986. W konsekwencji mechanizm ochrony tożsamości przekierowań HTTP w gix-transport (can_reuse_identity) porównuje niewłaściwy host i zawodzi w trybie otwartym. Atakujący kontrolujący odpowiedź przekierowania może stworzyć nagłówek Location w postaci <authority-atakującego>?@<oryginalne-authority>, aby gitoxide wysłał poświadczenia HTTP Basic Authorization wywołującego do niezamierzonego hosta. gix-transport jest dotknięty w wersjach <= 0.49.0 (naprawione w 0.58.1).

Budibase Server przed wersją 3.41.3 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w punkcie końcowym importu zapytań, który nie waliduje adresów URL dostarczonych przez użytkownika przed pobraniem treści. Atakujący mogą przesyłać dowolne adresy URL, aby uzyskać odpowiedzi z wewnętrznych usług, w tym punktów końcowych metadanych chmury i innych ograniczonych zasobów sieciowych.

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ść 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 Server przed wersją 3.41.3 zawiera podatność na SSRF w punkcie końcowym weryfikacji źródła danych, która pozwala użytkownikom na poziomie buildera podawać dowolne adresy URL bez walidacji SSRF. Atakujący mogą wykorzystać to do wycieku wewnętrznych poświadczeń CouchDB, wysyłając żądania do serwerów kontrolowanych przez atakującego, uzyskując pełny dostęp do bazy danych w wdrożeniach chmurowych.

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 backend-core (@budibase/backend-core, używany przez @budibase/server) pomija zakres adresów współdzielonych 100.64.0.0/10 z domyślnej czarnej listy SSRF (DEFAULT_BLACKLIST) używanej przez podgląd zapytań REST. Gdy domyślna czarna lista jest aktywna (tj. samodzielne wdrożenie nie zdefiniowało BLACKLIST_IPS), uwierzytelniony użytkownik z uprawnieniami Buildera może wysłać żądanie podglądu zapytania REST do POST /api/queries/preview, kierując je do osiągalnego serwisu HTTP(S) w zakresie 100.64.0.0/10, co powoduje, że serwer wysyła żądanie do tego celu i zwraca odpowiedź przez przepływ podglądu. Według porady, nie zidentyfikowano wydanej poprawki w momencie publikacji; remediacja polega na dodaniu 100.64.0.0/10 do DEFAULT_BLACKLIST.

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.

W filebrowser od wersji 2.24.0 występuje wyścig w obsłudze przesyłania TUS, który pozwala uwierzytelnionym użytkownikom zapisywać poza zadeklarowaną długością Upload-Length poprzez wysyłanie równoczesnych żądań PATCH. Atakujący mogą wysyłać wiele jednoczesnych żądań PATCH na tym samym offsecie, aby ominąć walidację długości, co skutkuje plikami przekraczającymi zadeklarowany rozmiar i wyzwalaniem hooków zakończenia dla zbyt dużych przesyłek.

W filebrowser do wersji 2.63.23 nie są usuwane rekordy udostępniania, gdy udostępniony plik zostanie zmieniony nazwą (tylko usunięcie wyzwala czyszczenie). Rekord udostępniania jest powiązany ze ścieżką, więc przetrwa zmianę nazwy i pozostaje uśpiony (zwracając 404, gdy ścieżka jest pusta). Gdy później pojawi się nowy, niezwiązany plik pod oryginalną ścieżką — przez ponowne przesłanie, innego użytkownika z uprawnieniami do tworzenia lub hook — stary publiczny link udostępniania serwuje ten nowy plik z ustawieniami hasła i wygaśnięcia oryginalnego linku, nieoczekiwanie go ujawniając.