Katalog podatności CVE

W FileRise przed wersją 3.18.0 ścieżki folderów są spłaszczane do nazw plików metadanych poprzez zastępowanie separatorów i spacji myślnikami, przez co różne foldery (np. team/docs i team-docs) mogą współdzielić jeden plik metadanych. Użytkownik o niskich uprawnieniach, który kontroluje kolidujący folder i zna nazwę pliku docelowego, może zmodyfikować metadane, sprawić że cudzy plik wygląda na jego własny, a następnie go odczytać i zmodyfikować.

W FileRise przed wersją 3.18.0 udostępnione foldery z możliwością wysyłania oraz linki tylko do wysyłania nie odrzucają nazwy pliku docelowego, która już istnieje. Nieuwierzytelniony gość z ważnym tokenem udostępniania i hasłem może wysłać plik o tej samej nazwie i po cichu zastąpić jego zawartość, zachowując oryginalne metadane. Ten sam problem dotyczy zwykłych uwierzytelnionych wysyłek przez /api/upload/upload.php oraz użytkowników tylko do wysyłania bez prawa edycji istniejącego pliku.

W FileRise przed wersją 3.16.0 pusty lub brakujący plik users.txt jest traktowany jako świeża instalacja, nawet jeśli konfiguracja została już wcześniej ukończona. Jeśli utrata danych, obcięcie lub inna awaria opróżni magazyn użytkowników, nieuwierzytelniony zdalny atakujący może wykryć ponowne otwarcie trybu konfiguracji i utworzyć kolejne konto administratora. Aplikacja nie miała trwałego znacznika ukończenia konfiguracji niezależnego od modyfikowalnego magazynu użytkowników.

W FileRise przed wersją 3.16.0, gdy administrator włączył WebDAV, uwierzytelnianie Basic w FileRise WebDAV sprawdza tylko nazwę użytkownika i hasło przez AuthModel::authenticate() i nie wymusza skonfigurowanego czynnika TOTP. Atakujący znający prawidłowe poświadczenia podstawowe konta z włączonym TOTP może uwierzytelnić się w usłudze WebDAV bez drugiego czynnika i korzystać z uprawnień plikowych konta. Ścieżka logowania w przeglądarce wymusza TOTP, ale osobne wywołanie zwrotne public/webdav.php tego nie robiło.

W FileRise przed wersją 3.16.0 wdrożenia z włączonym AUTH_BYPASS ufają skonfigurowanemu nagłówkowi tożsamości reverse-proxy bez weryfikacji, że żądanie pochodzi z FR_TRUSTED_PROXIES. Gdy port backendu jest osiągalny bezpośrednio, nieuwierzytelniony atakujący może podać X-Remote-User i uzyskać sesję dla wskazanego konta, w tym konta administratora, bez hasła i MFA. Wada dotyczy tylko wdrożeń z włączonym uwierzytelnianiem przez nagłówki proxy i wystawioną niezaufaną ścieżką do backendu.

W OpenSIPS do wersji 3.6.8/4.0.1 funkcja rtpproxy_offer/rtpproxy_answer komponentu rtpproxy zawiera podatność powodującą odczyt poza zakresem pamięci. Atak może być zainicjowany zdalnie. Aktualizacja do wersji 3.6.9 lub 4.0.2 rozwiązuje problem.

W narzędziu sar2html w wersji 4.0.0 wykryto podatność typu SQL injection w funkcji updateDb w pliku sar2html.py, w komponencie przetwarzania archiwów. Manipulacja argumentem s2host pozwala na wstrzyknięcie kodu SQL. Atak można przeprowadzić zdalnie.

W FileRise przed wersją 3.23.0 uwierzytelniona tożsamość OIDC jest mapowana na konto lokalne przy użyciu zmiennych roszczeń preferred_username lub email, bez wymogu email_verified. Atakujący mogący uzyskać od dostawcy roszczenie kolidujące z istniejącą nazwą użytkownika może zalogować się jako to konto, w tym jako wbudowany administrator, nawet gdy automatyczne tworzenie kont jest wyłączone.

W FileRise przed wersją 3.23.0 nieudane próby weryfikacji TOTP są przechowywane w $_SESSION, co pozwala atakującemu posiadającemu ważne podstawowe poświadczenia konta na restart procesu logowania w nowej sesji i przywrócenie limitu prób. Umożliwia to dalsze zgadywanie kodów TOTP poza zamierzonym limitem pięciu prób.

W SonicWall Network Security Manager (NSM) on-prem wykryto podatność typu OS Command Injection występującą po uwierzytelnieniu, wynikającą z nieprawidłowej neutralizacji specjalnych elementów w poleceniach systemu operacyjnego. W określonych warunkach uwierzytelniony zdalny atakujący może wykonać dowolne polecenia systemowe, co prowadzi do zdalnego wykonania kodu.

W WeGIA przed wersją 3.8.6 plik sessionStart.php odzwierciedla atakujący-supplied cookie PHPSESSID w odpowiedzi Set-Cookie i używa DB_HOST jako domeny cookie. Jeśli ofiara uwierzytelnia się używając identyfikatora wybranego przez atakującego, atakujący może go ponownie użyć do przejęcia sesji. Odpowiedź ujawnia również wewnętrzną nazwę hosta bazy danych.

W WeGIA przed wersją 3.8.6 uwierzytelniony użytkownik z dostępem do modułu Material & Patrimônio może przesłać id_produto do web/html/matPat/restaurar_produto_desocultar.php, gdzie drugie extract($_REQUEST) nadpisuje wartość wcześniej oczyszczoną przez intval(). Surowa wartość jest wstawiana do zapytań UPDATE dla tabel produto, isaida i ientrada, umożliwiając wykonanie dowolnego SQL.

W InvoiceShelf w wersji 2.3.3 i wcześniejszych walidacja żądań masowego usuwania akceptuje identyfikatory rekordów bez konsekwentnego powiązania ich z company_id uwierzytelnionego użytkownika. Uwierzytelniony użytkownik może przesłać identyfikator innej firmy i usunąć rekordy międzyfirmowe.

W InvoiceShelf przed wersją 2.4.0 parametr orderByField przekazywany przez uwierzytelnionego użytkownika jest używany w wywołaniach orderBy w Invoice::scopeApplyFilters bez ograniczenia do identyfikatorów kolumn. Spreparowane wyrażenie SQL może trafić do klauzuli ORDER BY, umożliwiając ślepą ekstrakcję informacji z bazy danych.

W InvoiceShelf przed wersją 2.4.0 publiczne trasy faktur, wycen i płatności klienta używają numerycznego mailable_id z tokenu EmailLog bez weryfikacji mailable_type, a handlery JSON nie wymuszają EmailLog::isExpired. Token wydany dla jednego typu dokumentu może ujawnić dokument innej firmy, a wygasły token może pozostać ważny na trasach JSON.

W InvoiceShelf przed wersją 2.4.0 metody NotesController::show, update i destroy autoryzują tylko ogólną zdolność view notes lub manage notes i nie przekazują powiązanej z trasą notatki do NotePolicy, więc nie sprawdzają company_id docelowej notatki. Uwierzytelniony użytkownik personelu może odczytać, zmodyfikować lub usunąć szablony notatek innej firmy.

W InvoiceShelf przed wersją 2.4.0 endpoint POST /api/v1/estimates/{estimate}/convert-to-invoice autoryzuje tylko zdolność create-invoice i nie autoryzuje dostępu do powiązanej wyceny. Uwierzytelniony użytkownik może skopiować pozycje, ceny, sumy, podatki, notatki, walutę i dane klienta innej firmy do faktury w swojej firmie.

Rozszerzenie Markdown Preview Enhanced dla Visual Studio Code przed wersją 0.8.30 nie waliduje polecenia ani argumentów przesyłanych z webview. JavaScript działający w podglądzie może wywołać uprzywilejowane polecenia rozszerzenia, w tym modyfikację plików, wykonanie kodu, uruchomienie narzędzi eksportu i otwieranie dowolnych adresów URL. Wykorzystanie wymaga osobnej ścieżki wykonania JavaScript w webview, np. wstrzyknięcia przez .crossnote/head.html.

Rozszerzenie Markdown Preview Enhanced dla Visual Studio Code przed wersją 0.8.29 wykonuje pliki .crossnote/config.js i .crossnote/parser.js z repozytorium za pomocą vm.runInNewContext, co nie stanowi granicy bezpieczeństwa względem środowiska Node.js. Otwarcie pliku Markdown w złośliwym repozytorium automatycznie ładuje te pliki, a przejście po łańcuchu prototypów pozwala dotrzeć do konstruktora Function i obiektu process, umożliwiając wykonanie poleceń systemowych bez dalszej interakcji.

W narzędziu cemtan sar2html w wersji 4.0.0 funkcja index w pliku sar2html.py nie zabezpiecza argumentu sort, co prowadzi do wstrzyknięcia SQL. Atak można przeprowadzić zdalnie, a publicznie dostępny exploit może być wykorzystywany w atakach. Projekt został poinformowany o problemie, ale nie odpowiedział.