Katalog podatności CVE

W SonicWall Network Security Manager (NSM) on-prem wykryto podatność nieprawidłowej kontroli dostępu w ustawieniach eksportu. Uwierzytelniony zdalny atakujący może uzyskać dostęp do poufnych informacji, co może pozwolić na eskalację uprawnień do administratora lub przechwytywanie komunikacji innych użytkowników instancji NSM.

FileRise to samodzielnie hostowany menedżer plików. Od wersji 3.9.0 do 3.22.0 czyste instalacje manualne bez PERSISTENT_TOKENS_KEY lub metadata/persistent_tokens.key mogą aktywować opublikowany klucz zgodności legacy. Jeśli atakujący zdobędzie pliki kont lub konfiguracji zawierające szyfrogram, znany klucz zapasowy umożliwi odszyfrowanie sekretów TOTP lub poświadczeń. Problem naprawiono w wersji 3.22.0.

OpenAEV to platforma open source do planowania, harmonogramowania i przeprowadzania kampanii symulacji przeciwnika oraz testów. W wersjach przed 2.260622.0, przy domyślnej instalacji, punkty końcowe /api/player/** lessons mogą być wywoływane bez uwierzytelnienia i ufają parametrowi zapytania userId dostarczonemu przez klienta, nie weryfikując, czy wywołujący jest tym użytkownikiem lub członkiem ćwiczenia. Nieuwierzytelniony klient znający UUID ćwiczenia może odczytać pytania i odpowiedzi lessons-learned (w tym tożsamość autora każdej odpowiedzi) oraz tworzyć lub nadpisywać odpowiedzi przypisane dowolnemu użytkownikowi. Wersja 2.260622.0 zawiera poprawkę.

FileRise to samodzielnie hostowany menedżer plików. Przed wersją 3.21.0 FileRise zwracał zapisaną wartość branding.footerHtml przez nieuwierzytelnione publiczne API konfiguracji witryny bez sanityzacji po stronie serwera. Frontend FileRise sanityzuje tę wartość przed renderowaniem, ale surowy HTML był eksponowany przez API. Administrator musi najpierw zapisać złośliwą wartość stopki. Problem naprawiono w wersji 3.21.0.

FileRise to samodzielnie hostowany menedżer plików. Przed wersją 3.21.0 FileRise śledzi nieudane logowania tylko na podstawie kombinacji adresu IP źródła i nazwy użytkownika. Zdalny nieuwierzytelniony atakujący może rotować nazwy użytkowników, aby uzyskać świeży budżet prób dla każdej nazwy, umożliwiając password spraying z jednego źródła poza zamierzonym limitem. Problem naprawiono w wersji 3.21.0.

FileRise to samodzielnie hostowany menedżer plików. Przed wersją 3.21.0 FileRise egzekwuje disableFormLogin, disableBasicAuth i disableOIDCLogin w interfejsie klienta, ale niekonsekwentnie w odpowiednich przepływach uwierzytelniania po stronie serwera. Użytkownik z ważnymi poświadczeniami dla wyłączonej metody może wywołać jej endpoint backendu bezpośrednio i uwierzytelnić się mimo polityki administratora. Problem naprawiono w wersji 3.21.0.

W FileRise przed wersją 3.20.0 punkt końcowy /api/file/snippet.php nie stosuje standardowej kontroli uwierzytelnionej sesji przed przetwarzaniem żądań podglądu krótkich tekstów. Endpoint nadal wykonuje kontrole ACL, więc typowe instalacje nie ujawniają nieuwierzytelnionego odczytu dowolnych plików, ale nieuwierzytelnione żądania docierają do oceny ACL zamiast natychmiastowej odpowiedzi 401. Jedynie nietypowe nagłówki proxy lub błędna konfiguracja ACL mogą pozwolić żądaniom wejść w obsługę ścieżek i zawartości plików.

FileRise przed wersją 3.19.0 nie odrzuca segmentów ścieżki typu ".." w parametrze folderName przed utworzeniem katalogu przez FolderModel::createFolder(). Uwierzytelniony użytkownik z niskimi uprawnieniami, ważnym tokenem CSRF oraz prawem tworzenia lub właściciela katalogu nadrzędnego może wysłać segmenty traversal do POST /api/folder/createFolder.php i utworzyć katalogi poza UPLOAD_DIR.

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.

FileRise przed wersją 3.16.0 przechowuje flagę isAdmin w tokenach remember-me i przywraca tę nieaktualną wartość podczas automatycznego logowania, zamiast odczytywać bieżącą rolę konta z users.txt. Użytkownik, któremu wydano token, gdy był administratorem, może zachować uprawnienia administratora po degradacji, a rotacja tokenów kopiuje ten nieaktualny przywilej do każdego nowego tokenu.

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.

FileRise przed wersją 3.16.0 nie stosuje UploadNamePolicy::isAllowedForWrite() przed zapisem wpisów przez ZipArchive::extractTo() do katalogu docelowego. Uwierzytelniony użytkownik z uprawnieniami do przesyłania i rozpakowywania może umieścić zablokowane rozszerzenie, takie jak plik z rodziny PHP, w archiwum ZIP i spowodować jego zapis na dysku, nawet gdy zwykłe przesyłanie odrzuca taką nazwę pliku.

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 OAID Tengine do wersji 1.12.0 wykryto podatność w funkcji get_tm_file_model w pliku source/serializer/tmfile/tm2_serializer.c komponentu tmfile Model Loader. Manipulacja argumentem offset_root prowadzi do odczytu poza granicami bufora. Atak można przeprowadzić zdalnie, a exploit został publicznie ujawniony.

W OpenClaw ClawScan do wersji 0.1.6 wykryto lukę w funkcji shouldSkipTargetPath w pliku internal/runner/runner.go komponentu Static Scanner. Manipulacja prowadzi do awarii mechanizmu ochrony. Atak wymaga dostępu lokalnego, a exploit został publicznie ujawniony.

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.

FileRise Pro przed wersją 3.24.0 w punkcie /api/pro/portals/get.php zwraca pełny wewnętrzny rekord skonfigurowanego portalu klienta nieuwierzytelnionemu wywołującemu, który zna lub odgadnie slug portalu. Odpowiedź zawiera wewnętrzną ścieżkę folderu przechowywania, e-mail kontaktowy klienta, ustawienia formularza i szczegóły polityki przesyłania, podczas gdy osobny punkt publicMeta.php celowo udostępnia tylko wyselekcjonowane dane brandingowe.