Katalog podatności CVE

W MinIO do wersji RELEASE.2025-10-15T17-29-55Z funkcja globalDeploymentID/SessionTokenAuthenticate w pliku cmd/common-main.go komponentu Embedded Console używa zaszyfrowanego na stałe klucza kryptograficznego. Atak można przeprowadzić zdalnie, a exploit został publicznie ujawniony.

W Nerimity Desktop do wersji 2.2.2 funkcja shell.openExternal w pliku src/mainWindow.js komponentu Window Open Handler nieprawidłowo autoryzuje obsługę niestandardowych schematów URL. Manipulacja argumentem url pozwala na zdalne wykonanie ataku, a exploit został publicznie ujawniony.

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.

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 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.

W stosie USBX hosta występuje podatność polegająca na tym, że podczas przetwarzania deskryptora raportu HID sprawdzanie poprawności rozmiaru następuje po przejściu nagłówka i parsowaniu ładunku, a analiza nie porównuje zadeklarowanych rozmiarów z rzeczywistymi danymi. Urządzenie HID zwracające skrócony deskryptor raportu powoduje odczyt poza granicami bufora sterty podczas zwykłej enumeracji.

W stosie USBX hosta występuje podatność w interfejsie VideoStreaming, gdzie pole wTotalLength jest używane jako budżet do przeglądania deskryptorów bez porównania z rzeczywistym rozmiarem odebranego deskryptora konfiguracji. Urządzenie raportujące większy wTotalLength niż dostarczone deskryptory powoduje odczyt poza granicami bufora konfiguracji.