Katalog podatności CVE

Biblioteka launch-editor przed wersją 2.14.2 nie wymusza traktowania ścieżki pliku jako argumentu pozycyjnego. Jeśli atakujący utworzy plik zaczynający się od plusa lub minusa, wybrany edytor (Vim, gVim, MacVim, Emacs, Emacsclient, Notepad++ z pluginem) zinterpretuje nazwę pliku jako flagę wiersza poleceń, co może doprowadzić do nadpisania plików lub wykonania dowolnych poleceń.

Biblioteka launch-editor przed wersją 2.14.2 nie escapowała znaku % na Windows podczas przekazywania argumentu do cmd. Jeśli zmienna środowiskowa zawierała złośliwą wartość, mogło dojść do wykonania jej zawartości.

launch-editor-middleware przed wersją 2.14.2 nieprawidłowo przetwarza kontrolowany przez atakującego argument pliku Windows kończący się składnikiem katalogu nadrzędnego oraz sufiksem linii i kolumny. Ścieżka jest rozwiązywana z sufiksem, a następnie sufiks jest usuwany przed sprawdzeniem existsSync, co pozwala ominąć walidację istnienia pliku. W połączeniu z osobną luką rozwijania procentów w Windows może prowadzić do wstrzyknięcia poleceń systemowych.

W filelock od wersji 4.1.0 do 4.2.1 klasy SoftReadWriteLock i AsyncSoftReadWriteLock buforują pomyślne sprawdzenie drzewa blokad <path>.rw i ponownie rozwiązują jego nazwy podczas późniejszych operacji zapisu, co pozwala innemu lokalnemu użytkownikowi, który może zastąpić to drzewo po pierwszym przejęciu, przekierować zapisy rekordów blokad do katalogów zapisywalnych przez użytkownika blokady.

W filelock od wersji 3.20.4 do 4.2.1 ReadWriteLock pozwala SQLite na ponowne otwieranie bazy danych i plików towarzyszących po nazwie. Na systemach POSIX atakujący z prawem do zmiany nazw w katalogu nadrzędnym bez sticky bit może podmienić te nazwy, powodując nadpisanie lub usunięcie plików; do nadpisania treści wybranej przez atakującego wymagany jest dodatkowo zapisywalny sąsiedni hot journal.

W bibliotece filelock od wersji 3.22.0 do 4.2.1 mechanizm SoftFileLock ufał sfałszowanemu identyfikatorowi procesu w znaczniku, który atakujący mógł modyfikować, ale nie usuwać. Umożliwiało to innemu procesowi tego samego konta lub rootowi działanie jako confused deputy, usunięcie aktywnego znacznika i dopuszczenie kolejnego posiadacza blokady.

W bibliotece filelock od wersji 4.1.0 do 4.2.1 mechanizm ReadWriteLock mógł usuwać losowy prywatny katalog twardych dowiązań .filelock-* podczas czyszczenia. Inny lokalny użytkownik z prawem zmiany nazw w katalogu nadrzędnym bez sticky bit mógł obserwować aktywną nazwę lub sfałszować nazwę sweep i podmienić katalog siostrzany do usunięcia.

W bibliotece filelock od wersji 3.20.4 do 4.0.9 mechanizmy ReadWriteLock i AsyncReadWriteLock rozwiązywały ścieżkę blokady i przekazywały ją do SQLite bez odrzucenia końcowego dowiązania symbolicznego. Inny lokalny użytkownik mogący tworzyć nazwy w katalogu blokady mógł przekierować tworzenie bazy danych lub rozdzielić wzajemne wykluczenie między celami.

W bibliotece filelock od wersji 3.22.0 do 4.2.1 mechanizm SoftFileLock mógł usunąć aktywny znacznik po tym, jak atakujący zwolnił własny znacznik po odczycie stanu nieaktualnego, uczciwy konkurent utworzył następcę na ponownie użytym i-węźle, a czas modyfikacji następcy nie był nowszy niż zapisana obserwacja. Prowadziło to do usunięcia aktywnego znacznika i dopuszczenia dwóch posiadaczy.

W bibliotece filelock od wersji 4.0.0 do 4.2.1 mechanizm SoftReadWriteLock odświeżał rekordy posiadaczy po nazwie. Inny lokalny użytkownik z prawem zmiany nazw w katalogu blokady mógł zastąpić rekord nazwanym potokiem i zablokować blokadę lub, przy permisywnej polityce twardych dowiązań, podlinkować osiągalny plik docelowy i spowodować zapis przez niego.

W bibliotece filelock od wersji 3.20.4 do 4.2.1 mechanizm ReadWriteLock mógł otworzyć spreparowaną bazę danych blokady SQLite bez ograniczenia pracy schematu i zapytań. Inny lokalny użytkownik mogący zastąpić bazę danych mógł spowodować zawieszenie lub zablokowanie pozyskiwania blokady.

W bibliotece filelock od wersji 4.1.0 do 4.2.1 mechanizm SoftFileLock mógł przywrócić nieaktualny znacznik po nazwie po jego odsunięciu. Inny lokalny użytkownik z prawem zmiany nazw w katalogu blokady bez sticky bit mógł podstawić dowiązanie symboliczne i, w środowisku podążającym za dowiązaniem oraz z celem w tym samym systemie plików, spowodować utworzenie twardego dowiązania do pliku użytkownika blokady.

W filelock od wersji 3.32.6 do 4.2.1 klasa SoftFileLock może podążać za podmienionym dowiązaniem symbolicznym podczas warunkowego sprawdzenia zapisywalności os.access dla węzła bez bitu zapisu właściciela. Pozwala to innemu lokalnemu użytkownikowi na platformie i w konfiguracji katalogu, które podążają za dowiązaniem, wywnioskować na podstawie obserwowalnego wyniku przejęcia, czy wybrana ścieżka istnieje i jest zapisywalna.

W bibliotece filelock od wersji 3.30.0 do 4.2.1 mechanizmy StrictSoftFileLock (od 3.30.0) i SoftReadWriteLock (od 4.0.0) mogły przyjąć katalog protokołu utworzony wcześniej przez innego lokalnego użytkownika we współdzielonym katalogu nadrzędnym. Umożliwiało to temu użytkownikowi zmianę stanu protokołu i dopuszczenie równoczesnych posiadaczy.

Biblioteka filelock w wersjach przed 4.2.1 ma podatność w UnixFileLock, która może obciąć zwykły plik przeniesiony na ścieżkę blokady, jeśli inny lokalny użytkownik ma uprawnienia do zmiany nazwy lub twardego linku. W wersjach od 3.10.2 może również zmienić tryb tego pliku, gdy żądany jest jawny tryb.

W bibliotece filelock w wersjach od 4.1.0 do 4.2.1 podatność w SoftFileLock pozwala na ponowne użycie nieaktualnej obserwacji, gdy atakujący wcześniej utworzy i usunie własny znacznik, a co najmniej dwa procesy oczekują. Może to spowodować usunięcie aktywnego znacznika jako nieaktualnego.

Wtyczka WordPress Seriously Simple Podcasting w wersjach do 3.17.0 zawiera podatność braku autoryzacji, która pozwala na wykorzystanie błędnie skonfigurowanych poziomów kontroli dostępu.

Wtyczka WordPress Seriously Simple Podcasting w wersjach do 3.17.0 zawiera podatność Cross-site Scripting (XSS) typu stored, wynikającą z niewłaściwej neutralizacji danych wejściowych podczas generowania stron internetowych.

A2A Java SDK w wersjach przed 1.3.0.Final ma podatność w RestHandler.parseRequestBody, która powoduje logowanie całego ciała żądania JSON na poziomie SEVERE, gdy parsowanie protobuf zawiedzie. Gdy powiadomienia push są włączone, może to ujawnić tokeny i dane uwierzytelniające w logach serwera.

A2A Java SDK w wersjach przed 1.3.0.Final ma podatność w BasePushNotificationSender, która wysyła dane zadania na adres URL bez walidacji miejsca docelowego, ograniczeń schematu ani limitów przekierowań. Nieuwierzytelniony atakujący może zarejestrować dowolny adres docelowy, powodując wysyłanie żądań z serwera do wewnętrznych lub lokalnych zasobów.