Katalog podatności CVE
Przetłumaczone opisy podatności z bazy NVD NIST - w języku polskim
Przeglądaj podatności według pakietuKatalog CISA KEV zaktualizowany: (v2026.11.04)
Cotygodniowy digest CVE
Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.
Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.
Menedżer pakietów MidnightBSD mport w wersjach przed 2.7.8 w poleceniu audit oblicza poprawione wartości local_argv i local_argc, ale przekazuje oryginalny argument do audit_package(). Gdy operator użyje opcji takiej jak -r przed nazwą pakietu, nieaktualny stan optind może spowodować audyt tokenu opcji zamiast żądanego pakietu, dając fałszywie negatywny wynik. Luka została naprawiona w wersji 2.7.8.
mport, menedżer pakietów MidnightBSD, przed wersją 2.7.8 w funkcji do_actual_install() w libmport/bundle_read_install_pkg.c używał operacji opartych na ścieżkach, takich jak lstat(), chown(), stat() i chmod(), podczas instalowania plików pakietu. Lokalny atakujący z prawem zapisu do katalogu docelowego mógł podmienić sprawdzany plik na dowiązanie symboliczne przed zastosowaniem uprzywilejowanych zmian właściciela lub trybu, przekierowując te zmiany na wybraną przez siebie ścieżkę i naruszając integralność systemu plików lub uprawnień.
mport, menedżer pakietów MidnightBSD, przed wersją 2.7.8 wykonywał uprzywilejowane operacje pobierania i czyszczenia pamięci podręcznej z użyciem podatnych na wyścigi operacji na ścieżkach w wielu plikach, takich jak libmport/fetch.c, libmport/clean.c, libmport/util.c, libmport/bundle_read_install_pkg.c, libmport/delete_primative.c i libexec/mport.create/mport.create.c. Lokalny atakujący z prawem zapisu do katalogu pamięci podręcznej lub ścieżki staging mógł wykorzystać wyścig między sprawdzeniem ścieżki a operacją zastąpienia, aby przekierować pobieranie pakietów, czyszczenie lub efekty uboczne instalacji poza zamierzoną pamięć podręczną. Dodatkowo, ścieżki pomocnicze używały wywołań w formie powłoki, co zwiększało ryzyko interpretacji argumentów.
SolarWinds Access Rights Manager został zgłoszony jako podatny na nieuwierzytelnione zdalne wykonanie kodu. Problem wynika z użycia wbudowanego, statycznego klucza.
BlueKitchen BTstack do wersji 1.8.2 nie weryfikuje liczby punktów końcowych zgłoszonych przez urządzenie względem rozmiaru tablicy podczas odkrywania punktów końcowych strumienia A2DP. Sparowane urządzenie może wysłać odpowiedź AVDTP DISCOVER z większą liczbą punktów końcowych niż mieści się w stałej tablicy, co powoduje zapisy poza zakresem, które uszkadzają sąsiednie obiekty statyczne i powodują awarię procesu lub przerwanie dostarczania zdarzeń.
RosarioSIS w wersjach przed 12.9 nie waliduje parametru żądania filename w modułach Users i Students, co pozwala uwierzytelnionym użytkownikom usuwać pliki z listy dozwolonych poprzez path traversal. Atakujący mogą użyć sekwencji katalogu nadrzędnego, aby wyjść poza katalogi przesyłania i usunąć zasoby CSS, XML, JSON oraz dokumenty innych użytkowników w całej instalacji.
RAGFlow do wersji 0.27.2 zawiera podatność na path traversal w endpointach dev_insert_chunks_from_file i dev_insert_metadata_from_file, która pozwala uwierzytelnionym atakującym na odczyt dowolnych plików poprzez podanie bezwzględnych ścieżek w parametrze file_path. Atakujący z ważnymi tokenami dostępu mogą wykorzystać brak walidacji ścieżek do odczytu dowolnych plików dostępnych dla usługi, przy czym ujawnienie jest ograniczone do plików pasujących do oczekiwanych struktur JSON, które są następnie zapisywane do zbiorów danych.
Wykryto podatność w vgmstream. Dotkniętym elementem jest funkcja init_vgmstream_awb_memory w pliku src/meta/awb.c komponentu parsera AWB. Taka manipulacja prowadzi do dzielenia przez zero. Atak może być wykonany zdalnie. Nazwa poprawki to ae37662ad626254ddd96ad69ac263792d7a92024. Należy zastosować poprawkę, aby rozwiązać ten problem.
Podatność w ash_authentication dotyczy strategii dynamic_oidc, która nie zapewnia prawidłowej separacji przestrzeni tożsamości między połączeniami. Atakujący kontrolujący jedno połączenie może zostać zalogowany jako lokalny użytkownik utworzony przez inne połączenie, ponieważ identyfikatory użytkowników nie są odpowiednio rozdzielane.
Appwrite przed wersją 2.0.0 zawiera podatność na wstrzyknięcie argumentów, która pozwala uwierzytelnionym użytkownikom z uprawnieniami functions.write lub sites.write na wykonanie dowolnych poleceń poprzez wstrzyknięcie znaków TAB do parametru providerRootDirectory używanego do budowania poleceń GNU tar. Aplikacja używa escapeshellcmd zamiast escapeshellarg i nie cytuje parametru, co pozwala znakom TAB przetrwać sanityzację i zostać zinterpretowanym jako separatory argumentów, umożliwiając wstrzyknięcie dowolnych argumentów GNU tar, takich jak --checkpoint-action=exec, w celu zdalnego wykonania kodu jako użytkownik procesu roboczego builds.
W narzędziu Backup w pgAdmin 4 nazwa bazy danych pochodząca z żądania była przekazywana do pg_dump jako pozycyjny argument bez walidacji. Ponieważ pg_dump używa getopt_long z permutacją argumentów, wartość zaczynająca się od myślnika (np. --file=/ścieżka) była interpretowana jako opcja, co pozwalało nadpisać wcześniej ustawiony parametr --file i zapisywać pliki poza katalogiem File Manager. To samo pole umożliwiało również wstrzyknięcie ciągu połączenia, przekierowując pg_dump na serwer atakującego wraz z hasłem bazy z zmiennej PGPASSWORD.
W pgAdmin 4 źródło uwierzytelniania 'webserver' miało podatność polegającą na tym, że funkcja WebserverAuthentication.get_user() w przypadku braku wartości w środowisku WSGI/CGI odczytywała nazwę użytkownika bezpośrednio z nagłówków HTTP przesyłanych przez klienta. W efekcie każdy klient mogący połączyć się z pgAdmin mógł podać własny nagłówek i zalogować się jako dowolny użytkownik, w tym istniejący Administrator, bez hasła. Problem dotyczy wersji od 6.2 do 9.18 i występuje tylko gdy w AUTHENTICATION_SOURCES włączone jest 'webserver'.
Podatność w pgAdmin 4 dotyczy narzędzi Restore i Maintenance, które przekazują pole 'database' bezpośrednio jako argument --dbname do pg_restore i psql. Wartość zawierająca znak równości jest rozwijana przez libpq do pełnego ciągu połączenia, co pozwala na przekierowanie połączenia na serwer wybrany przez atakującego. W wyniku tego może dojść do ujawnienia odszyfrowanego hasła bazy danych oraz możliwości nawiązywania połączeń wychodzących z hosta pgAdmin do dowolnych adresów sieciowych.
W pgAdmin 4 endpoint save_file w File Managerze sprawdzał uprawnienia do ścieżki za pomocą Filemanager.check_access_permission(), a następnie otwierał plik do zapisu zwykłym wywołaniem open(), bez flagi O_NOFOLLOW. W efekcie, jeśli w oknie czasowym między sprawdzeniem a zapisem podmieniono ostatni element ścieżki na dowiązanie symboliczne, zapis podążał za tym dowiązaniem i mógł utworzyć lub nadpisać dowolny plik z uprawnieniami konta systemowego pgAdmin. Luka dotyczy wersji pgAdmin 4 od wprowadzenia sprawdzania zawartości w ścieżce zapisu File Managera do wersji 9.18.
libp2p to implementacja stosu sieciowego libp2p w JavaScript. Przed wersją 11.0.26 @libp2p/floodsub akceptuje nieuwierzytelnione ramki RPC na /floodsub/1.0.0 przez PeerStreams.attachInboundStream bez limitów elementów protobuf, a następnie synchronicznie przetwarza tablicę subskrypcji bez limitu na ramkę. Pojedyncza ramka o ograniczonym rozmiarze może zdekodować się do milionów pustych wpisów subskrypcji blokujących pętlę zdarzeń, a setki tysięcy unikalnych tematów SUBSCRIBE alokują obiekty PeerSet w this.topics, które nie są usuwane po usunięciu lub zatrzymaniu peera. Puste wpisy powodują wyczerpanie CPU, ale nie zwiększają this.topics; trwały wzrost pamięci wymaga unikalnych tematów. Ścieżka subskrypcji omija walidację podpisu wiadomości i kolejkę przetwarzania tylko wiadomości, pozwalając zdalnemu peerowi na trwałą odmowę usługi CPU, wyczerpanie pamięci, zakończenie z powodu braku pamięci i niedostępność węzła. Problem został naprawiony w wersji 11.0.26.
libp2p to implementacja stosu sieciowego libp2p w JavaScript. Od wersji 8.0.0 do 12.0.24 @libp2p/peer-store w packages/peer-store/src/index.ts używa consumePeerRecord do weryfikacji podpisu RecordEnvelope, ale nie wymaga, aby PeerRecord.peerId w podpisanym ładunku był równy identyfikatorowi peera podpisującego uzyskanemu przez RecordEnvelope.openAndCertify. Opcja expectedPeer sprawdza tylko podpisującego kopertę, a ścieżka gossipsub Peer Exchange może podać identyfikator peera atakującego jako expectedPeer. Atakujący może zatem podpisać rekord swoim kluczem, umieścić identyfikator peera ofiary i kontrolowane przez atakującego multiadresy w ładunku, a certyfikowane adresy zostaną zapisane dla ofiary. Zatrute adresy mogą powodować uszkodzenie książki adresowej, przekierowanie lub niepowodzenie połączeń, manipulację routingiem i zakłócenie osiągalności, chociaż aktualizacja połączenia nadal weryfikuje tożsamość zdalnego peera i zapobiega całkowitemu przejęciu tożsamości. Problem został naprawiony w wersji 12.0.24.
libp2p to implementacja stosu sieciowego libp2p w JavaScript. Od wersji 15.0.0 do 16.0.5 @libp2p/gossipsub używa domyślnej polityki StrictSign w packages/gossipsub/src/utils/buildRawMessage.ts, gdzie validateToRawMessage weryfikuje podpis za pomocą kontrolowanego przez atakującego msg.key, ale pomija powiązanie tego klucza z msg.from, gdy deklarowanym autorem jest identyfikator peera RSA, który nie zawiera wbudowanego klucza publicznego. Nieuwierzytelniony atakujący może umieścić identyfikator peera ofiary RSA w msg.from, podpisać wiadomość swoim kluczem prywatnym i dostarczyć swój klucz publiczny w msg.key, powodując akceptację i propagację wiadomości jako autorstwa ofiary. Aplikacje, które ufają msg.from w walidatorach, autoryzacji, rozliczeniach, moderacji, reputacji lub logowaniu audytowym, mogą przetwarzać dane kontrolowane przez atakującego pod fałszywą atrybucją pochodzenia. Problem został naprawiony w wersji 16.0.5.
Soup Sieve to biblioteka selektorów CSS przeznaczona do użycia z Beautiful Soup 4. Przed wersją 2.9 parser selektorów w src/soupsieve/css_parser.py definiuje IDENTIFIER z sąsiadującymi grupami ilościowymi na nakładających się klasach znaków, a VALUE osadza IDENTIFIER dla selektorów atrybutów. Gdy selektor kontrolowany przez atakującego zawiera długi identyfikator lub niecytowany ciąg wartości atrybutu, po którym następuje dane wejściowe powodujące niepowodzenie ogólnego dopasowania, silnik wyrażeń regularnych przeszukuje kwadratowo wiele podziałów między nakładającymi się grupami. Selektory kontrolowane przez użytkownika mogą dotrzeć do tej ścieżki przez soupsieve.compile(), soupsieve.select() lub BeautifulSoup.select(), podczas gdy aplikacje używające tylko zakodowanych na stałe selektorów nie są dotknięte. Wynikające z tego zużycie CPU może utrzymać GIL Pythona, wyczerpać pracowników aplikacji i zatrzymać usługę; udane dopasowania zwykłych identyfikatorów są liniowe, a problem nie powoduje uszkodzenia pamięci ani wykonania kodu. Problem został naprawiony w wersji 2.9.
Soup Sieve to biblioteka selektorów CSS przeznaczona do użycia z Beautiful Soup 4. Przed wersją 2.9, selector_iter w src/soupsieve/css_parser.py przycina surowy selektor za pomocą RE_WS_END, wyrażenia kończącego się na WSC (białe znaki i komentarze) używanego z search(), więc silnik wyrażeń regularnych ponawia zachłanne skanowanie przy każdej pozycji początkowej. Selektor kontrolowany przez atakującego zawierający długi ciąg białych znaków wewnętrznych lub selektor zawierający długi ciąg komentarzy CSS, po którym następuje inny token, powoduje kwadratowe obciążenie CPU przed tokenizacją. Selektory kontrolowane przez użytkownika mogą dotrzeć do ścieżki przez soupsieve.compile() i BeautifulSoup.select(), podczas gdy aplikacje używające tylko zakodowanych na stałe selektorów nie są dotknięte. Ta przyczyna źródłowa jest oddzielona od podatności na cofanie się IDENTIFIER i VALUE, ponieważ koszt występuje w RE_WS_END.search podczas przycinania, a nie podczas dopasowywania tokenów. Wynikające z tego zużycie CPU może utrzymać GIL Pythona, wyczerpać pracowników i zatrzymać usługę bez powodowania uszkodzenia pamięci lub wykonania kodu. Problem został naprawiony w wersji 2.9.
Biblioteka AsyncHttpClient (AHC) w wersjach od 2.0.0 do 2.16.1 oraz 3.0.12 instaluje dekompresor odpowiedzi HTTP/1.1 bez limitu całkowitego rozmiaru zdekompresowanych danych. Złośliwy lub przejęty serwer może wysłać małą odpowiedź gzip, deflate lub snappy, która po dekompresji rozrasta się do ogromnych rozmiarów i wyczerpuje stertę klienta, powodując OutOfMemoryError. Problem dotyczy również brotli i zstd, a w wersjach 3.0.8–3.0.10 także dekompresora HTTP/2.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

