Katalog podatności CVE

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.

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

SiYuan przed wersją v3.8.1 zawiera podatność na SSRF w narzędziach agenta http_request i web_fetch, które wykonują rozwiązywanie DNS tylko w czasie guard, bez walidacji rozwiązywania w czasie połączenia. Atakujący mogą użyć DNS rebinding, aby odpowiedzieć na guard rozwiązywaniem z publicznym IP, a na połączenie z prywatnym lub metadata IP, omijając obronę SSRF i uzyskując dostęp do metadanych instancji chmury i usług wewnętrznych.

Rozszerzenie Joomla - Jefferson49 - Nieuwierzytelniona ślepa podatność SQLi w Sexy Polling Reloaded < 5.6.1.

W rozszerzeniu DP Calendar dla Joomla (digital-peak.com) w wersjach 7.0.0-8.19.5 oraz 9.0.0-10.12.0 występuje uwierzytelniona, uprzywilejowana podatność stored XSS. Tytuł lokalizacji jest renderowany w atrybucie data bez escapowania, co prowadzi do XSS; wymagane jest uprawnienie do tworzenia w DPCalendar.

Atakujący posiadający token przeznaczony do innego celu może się uwierzytelnić, ponieważ gdy odpowiedź tokena OAuth2 nie zawiera claimu scope, claim audience jest używany w jego miejsce i sprawdzany względem skonfigurowanych wymaganych zakresów. Są to różne koncepcje, a claim audience nie opisuje, co token może robić. Token, który nie przyznaje żadnych istotnych uprawnień, może zostać zaakceptowany, ponieważ jego wartość zamierzonego odbiorcy przypadkowo pasuje do skonfigurowanej nazwy zakresu, przyznając dostęp, który powinien być zabroniony. Ukrywa to również błędną konfigurację dostawcy tożsamości, gdzie zakresy nie są w ogóle wydawane. Upewnij się, że dostawca tożsamości wydaje claim scope dla wszystkich tokenów używanych z Dovecot i że skonfigurowane nazwy zakresów nie pasują do wartości audience. Zaktualizuj do niepodatnej wersji. Nie są znane publicznie dostępne exploity.

Nieuwierzytelniony atakujący może wysłać polecenie IMAP ID z bardzo dużą liczbą parametrów przed zalogowaniem, co powoduje nieproporcjonalny wzrost użycia pamięci i CPU. Proces logowania może zostać zakończony przez obsługę braku pamięci, co również kończy wszystkie inne połączenia obsługiwane przez ten sam proces. Może to powodować degradację lub odmowę usługi dla logowań IMAP. Ogranicz liczbę połączeń obsługiwanych przez pojedynczy proces imap-login. Ma to jednak wpływ na wydajność. Zaktualizuj do niepodatnej wersji. Nie są znane publicznie dostępne exploity.

Brak dostępnych informacji o podatności. Nie są znane publicznie dostępne exploity.

Nieuwierzytelniony atakujący może spowodować awarię procesu logowania ManageSieve, wysyłając małe, źle sformułowane polecenie przed uwierzytelnieniem. W trybie wysokiego bezpieczeństwa (domyślnym dla wydań społecznościowych) kończy się tylko połączenie atakującego. W trybie wysokiej wydajności (domyślnym dla wydań Pro) kończą się wszystkie połączenia obsługiwane przez ten sam proces managesieve-login. Powtarzanie ataku może spowodować denial of service dla zarządzania skryptami Sieve.

Atakujący, który może wysłać wiadomość do użytkownika, może stworzyć wiadomość z bardzo dużą liczbą adresów e-mail lub parametrów MIME w nagłówkach, co powoduje nadmierne zużycie pamięci podczas późniejszego parsowania wiadomości. Wiadomość jest nadal dostarczana, ale odczytanie jej przez IMAP może wyczerpać limit pamięci procesu i go zakończyć, powodując denial of service dla danego użytkownika.

W jądrze Linux naprawiono podatność w ptp: vmclock, która pozwalała na zmianę mapowania strony tylko do odczytu na zapisywalną. Funkcja vmclock_miscdev_mmap() odrzucała zapisywalne mapowania strony ABI vmclock z błędem -EROFS, ale pozostawiała flagę VM_MAYWRITE. Użytkownik mógł zmapować stronę jako tylko do odczytu, a następnie uaktualnić ją do zapisywalnej za pomocą mprotect(), co pozwalało gościowi na uszkodzenie danych czasu przechowywanych przez hosta (licznik sekwencji, czas UTC, offset TSC), które są zdefiniowane jako tylko do odczytu. Poprawka polega na wyczyszczeniu flagi VM_MAYWRITE na ścieżce tylko do odczytu, aby uniemożliwić uaktualnienie mapowania.

W jądrze Linux naprawiono podatność w of: reserved_mem, która powodowała zapis poza granicami tablicy, gdy zdefiniowano zbyt wiele dynamicznych regionów. Podczas uruchamiania funkcja fdt_scan_reserved_mem() zapisuje każdy dynamicznie umieszczony podwęzeł /reserved-memory do lokalnej tablicy o rozmiarze MAX_RESERVED_REGIONS. Jeśli drzewo urządzeń definiuje więcej niż MAX_RESERVED_REGIONS dynamicznie umieszczonych regionów, funkcja zapisuje poza koniec lokalnej tablicy. Poprawka dodaje sprawdzenie granic, które loguje błąd i pomija nadmiarowe regiony, przywracając oryginalne zachowanie.