Katalog podatności CVE

W Sync-in Server przed wersją 2.4.0 mechanizm blokady konta po nieudanych próbach TOTP nie działa, ponieważ licznik passwordAttempts nie jest zwiększany. Atakujący może zgadywać kody TOTP bez ograniczeń, a po trafieniu uzyskać token klienta wymienialny na pełny JWT, a także trwale wyłączyć MFA.

Sync-in Server to platforma open source do przechowywania, udostępniania, współpracy i synchronizacji plików. W wersjach przed 2.4.0 punkt końcowy POST /api/auth/token uwierzytelnia wyłącznie nazwą użytkownika i hasłem, a następnie wywołuje getTokens(), które zwraca pełne tokeny dostępu i odświeżania JWT bez sprawdzenia, czy konto ma włączone 2FA TOTP. Atakujący z ukradzionymi lub wyłudzonymi poświadczeniami może obejść 2FA w jednym żądaniu. Równoległy punkt końcowy logowania (POST /api/auth/login) poprawnie wymusza 2FA, wywołując setCookies(user, res, true), co jest uzależnione od user.twoFaEnabled. Wersja 2.4.0 naprawia ten problem.

Aplikacja luci-app-advanced-reboot dla OpenWrt przed wersją 1.1.2-6 przyznawała uprawnienie rpcd file.exec dla powłoki /bin/sh w ramach ACL tylko do odczytu. Uwierzytelniona sesja delegowana z tym ACL mogła przekazać kontrolowane przez wywołującego parametry, co pozwalało na wykonanie dowolnych poleceń jako root.

Aplikacja luci-app-adblock-fast dla OpenWrt przed wersją 1.2.4-2 pozwalała metodzie RPC luci.adblock-fast.setCronEntry przyjąć argument zawierający znaki powrotu karetki lub nowej linii i zapisać go w /etc/crontabs/root jako jedną linię logiczną. Uwierzytelniony delegowany użytkownik z ACL zapisu mógł utworzyć dodatkowy wpis cron roota, co prowadziło do trwałego wykonania poleceń jako UID 0.

W Tautulli przed wersją 2.17.2 nieuwierzytelniony endpoint /auth/redirect usuwa ukośniki z parametru redirect_uri, ale pozostawia znaki tabulacji, nowej linii i powrotu karetki. Przy domyślnej konfiguracji HTTP_ROOT pozwala to przekierować użytkownika na zewnętrzną domenę kontrolowaną przez atakującego.

Tautulli przed wersją 2.17.2 w handlerze import_config oraz w gałęzi database_file funkcji import_database łączy kontrolowaną przez atakującego nazwę pliku bezpośrednio z CACHE_DIR bez redukcji do basename ani sprawdzenia zawierania ścieżki. Administrator lub wywołujący z kluczem API instancji może przesłać nazwę pliku zawierającą segmenty katalogu nadrzędnego, powodując zapis lub nadpisanie pliku poza CACHE_DIR.

W Envoy przed wersjami 1.36.10, 1.37.6, 1.38.4 i 1.39.1 klient zewnętrznej autoryzacji HTTP może zachować nieaktualny callback po odrzuceniu żądania. Późniejsze przetworzenie odpowiedzi autoryzacyjnej wywołuje callback po zniszczeniu jego właściciela, powodując use-after-free i awarię procesu.

W Tautulli przed wersją 2.17.2 pole cron newslettera jest wstawiane do łańcucha JavaScript bez bezpiecznego kodowania JSON. Administrator lub osoba z kluczem API Tautulli może zapisać spreparowaną wartość cron, która wykona skrypt w kontekście webowym Tautulli, gdy administrator otworzy okno konfiguracji newslettera.

Dell Command | Monitor (DCM) w wersjach przed 10.13.2 zawiera podatność nieprawidłowego przypisania uprawnień do krytycznego zasobu. Nisko uprzywilejowany atakujący z dostępem lokalnym może potencjalnie wykorzystać tę podatność, prowadząc do podniesienia uprawnień.

W Envoy przed wersjami 1.36.10, 1.37.6, 1.38.4 i 1.39.1 funkcja allocateConnPool odwołuje się do transport_socket_options bez sprawdzenia, czy wskaźnik nie jest pusty. Przy włączonym auto_config i HTTP/3 zwykły ruch może wywołać awarię procesu roboczego Envoy.

W Tautulli przed wersją 2.17.2 endpoint /search wstawia kontrolowany przez użytkownika parametr zapytania do łańcucha JavaScript z ręcznym escapowaniem, które nie obsługuje odwrotnych ukośników. Sekwencja odwrotny ukośnik-cudzysłów może zakończyć łańcuch, umożliwiając nieuwierzytelnionemu atakującemu wykonanie skryptu w kontekście webowym Tautulli, gdy uwierzytelniony użytkownik kliknie spreparowany link.

jshERP do wersji 3.6 zawiera podatność obejścia autoryzacji w endpointach CRUD userBusiness, która pozwala uwierzytelnionym użytkownikom tworzyć, modyfikować lub usuwać wiersze relacji autoryzacyjnych bez sprawdzania uprawnień. Atakujący mogą manipulować mapowaniami użytkownik-rola i kontrolą dostępu, aby podnieść uprawnienia, odebrać dostęp innym kontom lub zmodyfikować relacje rola-funkcja dla dowolnego użytkownika w tenancie.

jshERP do wersji 3.6 nie weryfikuje własności obiektów w endpointach informacji, aktualizacji i usuwania po identyfikatorze w wielu typach zasobów. Uwierzytelnieni użytkownicy mogą odczytywać, modyfikować i usuwać obiekty biznesowe innych użytkowników, podając bezpośrednie identyfikatory obiektów bez sprawdzania autoryzacji.

jshERP do wersji 3.6 nie weryfikuje uprawnień wywołującego w endpointach zarządzania rolami, co pozwala uwierzytelnionym użytkownikom modyfikować zakres danych dowolnej roli lub usuwać role. Atakujący mogą wykorzystać endpointy /role/update i /role/delete, aby podnieść uprawnienia, zmienić widoczność danych na wszystkie dane i uzyskać dostęp do wszystkich rekordów biznesowych w tenancie.

jshERP do wersji 3.6 nie weryfikuje prawidłowo uprawnień użytkownika w SystemConfigService.updateSystemConfig, co pozwala uwierzytelnionym użytkownikom modyfikować konfigurację systemową tenanta. Atakujący mogą przepisać lub usunąć ustawienia obejmujące tożsamość firmy, reguły magazynowe, zachowanie zatwierdzeń i konfigurację drukowania przez endpoint systemConfig.

jshERP do wersji 3.6 zawiera podatność obejścia izolacji dzierżawców, która pozwala uwierzytelnionym użytkownikom odczytywać rekordy innych dzierżawców przez endpoint GET /tenant/info. Atakujący może iterować klucz główny, aby wyliczyć i uzyskać dostęp do danych wrażliwych, takich jak nazwy logowania, daty ważności, limity użytkowników i stan włączenia wszystkich dzierżawców platformy.

jshERP do wersji 3.6 nie sprawdza autoryzacji na endpoincie POST /userBusiness/updateBtnStr, co pozwala uwierzytelnionym użytkownikom modyfikować definicje uprawnień przycisków ról. Atakujący może podać dowolne parametry roleId i btnStr, aby nadpisać konfigurację uprawnień przycisków dla dowolnej roli w dzierżawie bez weryfikacji uprawnień.

jshERP do wersji 3.6 nie usuwa skrótów haseł w endpoincie /user/info, co pozwala uwierzytelnionym użytkownikom pobrać niesolone skróty MD5 haseł dowolnego użytkownika. Atakujący może podać identyfikatory użytkowników, aby uzyskać skróty haseł nadające się do łamania offline lub bezpośredniego obejścia uwierzytelniania.

jshERP do wersji 3.6 zawiera podatność obejścia autoryzacji w endpoincie POST /user/resetPwd, która pozwala uwierzytelnionym użytkownikom zresetować hasło dowolnego innego użytkownika. Atakujący może wysłać żądanie z dowolnym identyfikatorem użytkownika docelowego, aby zresetować hasło tego konta do znanej wartości domyślnej.

jshERP 3.6 zawiera podatność eskalacji uprawnień w endpoincie updateOneValueByKeyIdAndType, która pozwala uwierzytelnionym użytkownikom przyznać sobie dowolne role. Atakujący może wysłać żądanie POST z type=UserRole, własnym identyfikatorem użytkownika i listą identyfikatorów ról, aby awansować z nisko uprzywilejowanego użytkownika tenanta na administratora tenanta.