Katalog podatności CVE

W projekcie girishsaraf Online-Appointment-Booking-System wykryto podatność SQL injection w pliku book.php komponentu Booking Handler. Manipulacja argumentem Doctor/appointment pozwala na przeprowadzenie ataku zdalnie, a exploit został publicznie udostępniony.

W SSSD wykryto błąd, w którym usługa nie weryfikuje obecności rozszerzenia SID przed jego przetworzeniem w konfiguracjach z regułami mapowania certyfikatów opartymi na SID. Zdalny atakujący może przesłać certyfikat bez oczekiwanego rozszerzenia SID, powodując awarię procesu podczas uwierzytelniania lub wyszukiwania.

W SSSD wykryto błąd, w którym lokalny atakujący może wysłać spreparowane żądanie z nieprawidłową długością pakietu do gniazda UNIX respondera autofs. Powoduje to niedomiar liczby całkowitej i odczyt pamięci poza zakresem, co może doprowadzić do awarii procesu respondera.

Wtyczka NFS idmap w SSSD nie przerywa działania po wykryciu, że wpis w pamięci podręcznej przekracza rozmiar bufora docelowego, co prowadzi do zapisu poza zakresem. Lokalny atakujący może wywołać ten problem przez żądania tożsamości, które zwracają zbyt duże wpisy z pamięci podręcznej, powodując awarię usługi mapowania tożsamości (DoS) i potencjalne uszkodzenie pamięci sąsiednich procesów.

W responderze Kerberos Credential Manager (KCM) w SSSD występuje problem polegający na tym, że usługa nie zwalnia obiektów z pamięci po usunięciu poświadczeń. Lokalny użytkownik może utrzymywać trwałe połączenie i wielokrotnie przechowywać oraz niszczyć poświadczenia, co prowadzi do ciągłego wzrostu zużycia pamięci i ostatecznie do wyczerpania pamięci, czyniąc usługę nieodpowiadającą (DoS).

W responderze Kerberos Credential Manager (KCM) w SSSD występuje podatność use-after-free podczas odnawiania biletu TGT, gdzie odroczone wywołanie zwrotne uzyskuje dostęp do już zwolnionej pamięci. Uwierzytelniony lokalny użytkownik z odnawialnym biletem Kerberos może wywołać awarię usługi KCM, powodując Denial of Service (DoS).

W SSSD, gdy skonfigurowano egzekwowanie wygaśnięcia konta przy użyciu atrybutów shadow LDAP, wartość wygaśnięcia równa zero nie jest traktowana jako konto wygasłe. Użytkownik z ważnymi poświadczeniami dla wygasłego konta może wykorzystać tę lukę, aby ominąć kontrolę dostępu i uwierzytelnić się w systemie, co pozwala na nieautoryzowany dostęp po dezaktywacji konta.

W SSSD nieuprzywilejowany lokalny użytkownik może wielokrotnie żądać aktualizacji głównej mapy automount przez responder autofs z powodu braku kontroli autoryzacji. To powoduje globalne unieważnienie pamięci podręcznej i wymusza powtarzane zapytania do dostawców katalogów, prowadząc do Denial of Service (DoS) z powodu obniżonej dostępności automount i zwiększonego zużycia zasobów.

W SSSD, gdy włączony jest responder autofs, pamięć przydzielona podczas przetwarzania udanych żądań nie jest zwalniana aż do zakończenia połączenia klienta. Lokalny atakujący może wykorzystać tę podatność, utrzymując otwarte połączenie i wielokrotnie wysyłając poprawne żądania, co prowadzi do wyczerpania pamięci i Denial of Service (DoS).

Joplin Server przed wersją 3.7.2 przechowuje tokeny CSRF, potwierdzenia konta, zmiany e-maila i resetowania hasła bez celu, a UserModel.resetPassword akceptuje dowolny token zwrócony przez TokenModel.userFromToken. Atakujący, który zdobędzie token CSRF lub potwierdzenia ofiary przez osobny kanał ujawnienia, może wysłać go do publicznego punktu resetowania hasła, zmienić hasło ofiary i spowodować usunięcie istniejących sesji i aplikacji API. Problem naprawiono w Joplin Server 3.7.2.

W Joplin przed wersją 3.7.13, wybranie notatki zawierającej fence jsoncanvas powoduje, że komponenty whiteboard text i file-node renderują zawartość karty z pełnym rendererem Markdown, a następnie wstawiają wynikowy HTML do głównego dokumentu aplikacji przez dangerouslySetInnerHTML. Złośliwa notatka może wstrzyknąć elementy stylów i zdalne importy CSS, które modyfikują zaufane elementy aplikacji, sygnalizują otwarcie notatki i mogą ujawnić wartości atrybutów. Content Security Policy blokuje wykonanie skryptów inline, więc wpływ obejmuje wstrzyknięcie CSS i podmianę UI, a nie wykonanie kodu. Problem naprawiono w wersji 3.7.13.

W vLLM przed wersją 0.30.0, wywołujący może użyć pola media_io_kwargs do wybrania backendu wideo GLMGA i podać duże wartości fps i max_frames bez ścisłego limitu pracy, co prowadzi do nadmiernego zużycia CPU i pamięci.

W vLLM przed wersją 0.30.0, middleware track_http_metrics w Rust frontendzie rejestruje surowy token metody HTTP jako etykietę Prometheus dla żądań do zarejestrowanych tras, co pozwala nieuwierzytelnionemu atakującemu na tworzenie unikalnych etykiet i zwiększanie zużycia pamięci.

W vLLM od wersji 0.24.0 do 0.30.0, klasy Qwen2VLVideoBackend i Qwen3VLVideoBackend akceptują wartości max_frames i fps z żądania bez narzucania limitów serwerowych, co pozwala nieuwierzytelnionemu wywołującemu na dekodowanie każdej klatki z kontrolowanego wideo i zużywanie nadmiernej pamięci.

W vLLM przed wersją 0.30.0, błędy w żądaniach z ograniczeniami struktury mogą uciec z walidacji i trafić do ścieżki błędu krytycznego EngineCore, co pozwala zwykłym żądaniom z ograniczeniami na przerwanie działania współdzielonego silnika.

W vLLM przed wersją 0.30.0, modele żądań zgodne z OpenAI akceptują niepustą wartość cache_salt bez egzekwowania ograniczeń znaków i długości wymaganych przez IPCCacheServerKey w LMCache-MP, co może prowadzić do nieobsłużonego ValueError i przerwania działania EngineCore.

W vLLM przed wersją 0.30.0, scoring late-interaction na /score i /rerank wyprowadza query_key z nagłówka X-Request-Id kontrolowanego przez wywołującego, co pozwala współbieżnemu żądaniu na nadpisanie zakodowanego zapytania ofiary.

W vLLM przed wersją 0.30.0, endpoint /inference/v1/generate w ścieżce disaggregated scale-out akceptuje tensory, identyfikatory cache, zakresy i procesory pól multimodalnych kontrolowane przez wywołującego bez powiązania ich z kontraktem renderera, co może prowadzić do przerwania EngineCore, zatrucia cache lub zmiany semantyki transportu.

W vLLM przed wersją 0.28.0, domyślny lustrzany multimodalny LRU cache może zatwierdzić hash mediów w cache wysyłającym frontendu podczas renderowania multimodalnego, zanim żądanie zostanie zaakceptowane przez silnik, a jeśli żądanie jest odrzucone, cache odbierający nie otrzyma payloadu, co prowadzi do błędu asercji przy późniejszym użyciu tego samego hasha.

Złośliwy frontend może przesłać definicję LLB, która powoduje panikę i zakończenie działania buildkitd, przerywając wszystkie buildy uruchomione na tym demonie.