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.08.27)
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.
grpc-gateway v2.28.0 jest podatny na nieprawidłową kontrolę dostępu. Aplikacja przetwarza nagłówek X-HTTP-Method-Override w ServeMux.ServeHTTP bez ograniczania dozwolonych metod. Gdy żądanie POST z Content-Type application/x-www-form-urlencoded zawiera ten nagłówek, metoda żądania jest przepisywana na dowolną wartość dostarczoną przez atakującego przed routingiem. Pozwala to na ominięcie kontroli dostępu opartych na metodach egzekwowanych przez proxy lub WAF.
W routerze CP Plus CP-XR-DE21-S występuje podatność polegająca na obecności zaszytych na stałe poświadczeń uwierzytelniania HTTP Digest w oprogramowaniu układowym, które są identyczne dla wszystkich urządzeń z tym oprogramowaniem. Atakujący z dostępem do sieci lokalnej może wykorzystać tę podatność, uzyskując poświadczenia z oprogramowania układowego.
Morgan, middleware do logowania żądań HTTP dla Node.js, w wersjach przed 1.12.0 nie neutralizował znaków separatora linii Unicode U+0085, U+2028 i U+2029 w wartościach tokenów logów. Zdalny klient może umieścić te znaki w kontrolowanym tokenie, np. w nazwie użytkownika Basic auth, co powoduje, że proces logowania rozdziela pojedynczy wpis na wiele rekordów. Jest to problem fałszowania logów (CWE-117) i niekompletna poprawka CVE-2026-5078. Problem naprawiono w wersji 1.12.0.
To CVE zostało odrzucone. ID zostało przypisane do zgłoszonej podatności w wtyczce Customer Reviews for WooCommerce WordPress, ale nigdy nie zostało opublikowane. Zgłoszenie zostało wycofane: warunek wstępny, na którym polegało, czyli uzyskanie przez atakującego identyfikatora formularza recenzji należącego do klienta, do którego nie ma już dostępu, nie mógł zostać wykazany. Nie wydano żadnego biuletynu dla tego ID.
Platforma Pega Platform w wersjach od 7.1.0 do 25.1.2 jest dotknięta podatnością nieprawidłowej walidacji danych wejściowych używanych w warunkach pętli, co może prowadzić do nadmiernego zapętlania, a w konsekwencji do odmowy usługi lub innych skutków.
SvelteKit w wersjach od 2.49.0 do 2.52.1 z włączonymi eksperymentalnymi funkcjami zdalnymi i formularzami zawiera podatność na wyczerpanie CPU podczas deserializacji formularzy. Atakujący może wysłać złośliwe dane formularza, powodując brak reakcji serwera podczas przetwarzania żądania, co prowadzi do odmowy usługi. Problem naprawiono w wersji 2.52.2.
SvelteKit w wersjach od 2.49.0 do 2.52.1 z włączonymi eksperymentalnymi funkcjami zdalnymi i formularzami zawiera podatność na wyczerpanie pamięci podczas zdalnej deserializacji formularzy. Złośliwe dane formularza mogą powodować nadmierną alokację pamięci, co prowadzi do awarii procesu serwera i odmowy usługi. Problem naprawiono w wersji 2.52.2.
SvelteKit w wersjach od 2.49.0 do 2.53.2 (naprawione w 2.53.3) zawiera problem z ekspansją deserializacji w eksperymentalnej funkcji zdalnej formularza. Gdy aplikacja włącza experimental.remoteFunctions i używa funkcji form do przetwarzania tablicy plików bez walidacji files.length lub rozmiarów poszczególnych plików, atakujący może przesłać stosunkowo małe dane, które rozwijają się w bardzo duże tablice plików, prowadząc do kosztownego przetwarzania i odmowy usługi.
SvelteKit w wersjach od 2.38.0 do 2.60.1 zawiera wyścig w query.batch, który pozwala na połączenie równoczesnych żądań od różnych użytkowników w jeden kontekst żądania. Atakujący mogą wykorzystać specyficzne warunki czasowe, aby uzyskać dostęp do wrażliwych danych z równoczesnych żądań innych użytkowników.
SvelteKit przed wersją 2.69.1 zawiera podatność na zanieczyszczenie prototypu w zdalnych funkcjach formularzy z polami plików, które akceptują dowolne nazwy ścieżek kontrolowane przez użytkownika. Atakujący mogą manipulować ścieżką usuwania, aby usunąć metody z prototypu, potencjalnie wyłączając funkcjonalność aplikacji.
SvelteKit przed wersją 2.69.1 nie waliduje poprawnie rozmiarów ładunków w zdalnych funkcjach formularzy, co pozwala atakującym na awarię procesu Node przez wysyłanie dużych ładunków. Wielokrotne wykorzystanie powoduje denial of service przez ciągłe awarie procesu aplikacji.
gitoxide w wersjach od 0.25.4 zawiera podatność na wyciek poświadczeń HTTP w backendzie transportowym opartym na curl, gdzie poświadczenia są wysyłane do serwerów kontrolowanych przez atakującego po przekierowaniach HTTP. Podatność występuje, ponieważ walidacja poświadczeń sprawdza oryginalny URL zamiast efektywnego URL po przekierowaniu, co pozwala atakującym na kradzież tokenów uwierzytelniających przez przekierowania między domenami lub degradację HTTPS do HTTP.
gitoxide przed wersją 0.69.0 zawiera niesprawdzane indeksowanie tablicy podczas aplikowania delt oraz nieograniczoną alokację pamięci na podstawie rozmiarów kontrolowanych przez atakującego w nagłówkach w gix-pack. Atakujący mogą wysłać spreparowane dane pakietu podczas klonowania lub pobierania, aby wywołać panikę lub zabicie procesu z powodu braku pamięci.
gitoxide (crates Rusta gix <= 0.72.0 i gix-validate <= 0.10.0) zawiera podatność na przechodzenie po ścieżkach. Funkcja walidacji nazw podmodułów w gix-validate sprawdza tylko pierwsze wystąpienie '..' przez name.find(b".."), co pozwala na obejście walidacji przez spreparowane nazwy takie jak 'a..b/../../../.git/'. Dodatkowo ta walidacja nie jest wywoływana w ścieżkach produkcyjnych. W połączeniu z wadą dziedziczenia zaufania w Submodule::open(), gdzie git_dir_trust (Trust::Full) repozytorium nadrzędnego jest klonowane i pomijana jest weryfikacja własności, atakujący może stworzyć złośliwy plik .gitmodules, aby narzędzie ofiary zbudowane na gitoxide czytało dowolną konfigurację repozytorium git (w tym osadzone poświadczenia) z pełnym zaufaniem, omijając ochronę safe-directory. Naprawione w gix 0.82.0 i gix-validate 0.11.1.
gitoxide przed wersją 0.52.1 podąża za dowiązaniami symbolicznymi podczas odczytu pliku .gitmodules w katalogu roboczym, co pozwala atakującym na wstrzyknięcie bajtów spoza repozytorium do metadanych podmodułów. Atakujący mogą stworzyć złośliwe repozytorium z dowiązaniem symbolicznym .gitmodules wskazującym poza drzewo repozytorium, powodując, że gitoxide parsuje dowolne zewnętrzne pliki jako konfigurację podmodułów i ujawnia kontrolowane przez atakującego wartości name, path i url.
gitoxide przed wersją 0.52.1 nie waliduje nazw podmodułów z konfiguracji .gitmodules, co pozwala na przechodzenie po ścieżkach podczas wyznaczania katalogów git podmodułów. Atakujący mogą stworzyć złośliwe nazwy podmodułów z segmentami przechodzenia, aby przekierować funkcje state() i open() do repozytoriów poza .git/modules, powodując zamieszanie repozytoriów i inspekcję repozytoriów kontrolowanych przez atakującego.
gitoxide gix-packetline przed wersją 0.21.5 zawiera podatność na panikę w implementacji TextRef, która występuje podczas przetwarzania pakietów side-band z pustymi ładunkami. Złośliwy serwer Git może wysłać spreparowany pakiet side-band, aby wywołać panikę z powodu indeksu poza zakresem, co powoduje przerwanie procesu klienta podczas operacji fetch bez uwierzytelnienia.
W gitoxide przed wersją 0.38.2 nie są poprawnie walidowane znaki powrotu karetki w wartościach URL przekazywanych do pomocników poświadczeń. Atakujący mogą dostarczyć URL zawierające gołe powroty karetki, aby wstrzyknąć dodatkowe pola protokołu pomocnika i spowodować, że pomocnicy zwrócą poświadczenia dla hostów wskazanych przez atakującego zamiast żądanego URL.
Podatność w gix-worktree-state przed wersją 0.33.0 (część gitoxide) umożliwia zapisywanie plików poza katalogiem roboczym w systemie Windows. Funkcja checkout() podąża za istniejącym terminalnym dowiązaniem symbolicznym podczas przyrostowej materializacji, co pozwala nadpisać pliki poza katalogiem roboczym.
Crate gix-url w gitoxide (<= 0.32.0, naprawione w 0.37.1) używa ręcznie napisanego parsera URL, który nie traktuje '?' ani '#' jako końca komponentu authority, wbrew RFC 3986. W konsekwencji mechanizm ochrony tożsamości przekierowań HTTP w gix-transport (can_reuse_identity) porównuje niewłaściwy host i zawodzi w trybie otwartym. Atakujący kontrolujący odpowiedź przekierowania może stworzyć nagłówek Location w postaci <authority-atakującego>?@<oryginalne-authority>, aby gitoxide wysłał poświadczenia HTTP Basic Authorization wywołującego do niezamierzonego hosta. gix-transport jest dotknięty w wersjach <= 0.49.0 (naprawione w 0.58.1).

