Katalog podatności CVE

Nieprawidłowa obsługa niespójności parametru długości w demonie protokołu routingu (rpd) w Juniper Networks Junos OS i Junos OS Evolved pozwala atakującemu wysłać specjalnie zniekształconą aktualizację multicast BGP EVPN, która przy próbie readwersji powoduje awarię rpd.

Dereferencja wskaźnika NULL w matcherze nexthop-ECMP polityki routingu w Juniper Networks Junos OS i Junos OS Evolved pozwala skonfigurowanemu sąsiadowi eBGP wywołać odmowę usługi demona routingu poprzez specjalny pakiet BGP odebrany, gdy kwalifikator nexthop-ecmp jest dołączony do polityki importu BGP.

Podatność polegająca na wywołaniu funkcji z nieprawidłową zmienną lub referencją jako argumentem w demonie protokołów routingu (rpd) systemów Juniper Networks Junos OS oraz Junos OS Evolved. Nieuwierzytelniony atakujący z sąsiedniej sieci może doprowadzić do awarii rpd poprzez specjalnie zniekształcone pakiety LSP-ping.

Podatność niewłaściwego uwierzytelniania w interfejsie zarządzania J-Web oraz obsłudze sesji NETCONF systemów Juniper Networks Junos OS i Junos OS Evolved pozwala nieuwierzytelnionemu atakującemu sieciowemu uzyskać dostęp do konfiguracji urządzenia na poziomie root i przejąć urządzenie poprzez osiągalną usługę J-Web HTTP lub HTTPS, gdy zarządzanie przez sieć jest włączone.

Nieprawidłowa walidacja spójności danych wejściowych w demonie protokołu routingu (rpd) w Juniper Networks Junos OS i Junos OS Evolved pozwala skonfigurowanemu sąsiadowi BGP ISO-VPN wywołać awarię rpd poprzez wysłanie specjalnej aktualizacji ISO-VPN, która jest następnie przetwarzana przez monitorowanie tras BMP lub NSR.

Dereferencja wskaźnika NULL w demonie protokołu routingu (rpd) w Juniper Networks Junos OS i Junos OS Evolved pozwala nieuwierzytelnionemu zdalnemu sąsiadowi BGP wywołać odmowę usługi poprzez aktualizację BGP VPN-flowspec, jeśli jest ona readwersowana i skonfigurowane jest monitorowanie BMP post-policy RIB-out.

SeaweedFS to rozproszony system przechowywania plików i blobów. Od wersji 4.0.388 do 4.41 wykres SFTP Helm osadzał niezaszyfrowany prywatny klucz hosta Ed25519 w pliku k8s/charts/seaweedfs/templates/sftp/sftp-secret.yaml jako stringData.seaweedfs_sftp_ssh_private_key. Wdrożenie standalone prezentowało ten klucz publiczny, gdy sftp.enabled i sftp.enableAuth były prawdziwe, nie dostarczono sftp.existingConfigSecret, wybrano ścieżkę sftp.sshPrivateKey, ważny Secret config-ssh pozwalał na start, a hostKeysFolder nie zapewniał późniejszego podpisywania Ed25519. Atakujący mogący przekierować lub przechwycić ruch klienta mógł podszyć się pod ten punkt końcowy SFTP dla klientów ufających opublikowanej tożsamości hosta, ujawniając poświadczenia hasła lub dane wysyłane do fałszywego punktu końcowego. Domyślne ścieżki all-in-one i nieuwierzytelnione standalone nie ładowały klucza. Problem naprawiono w wersji 4.41.

Podatność typu nieskończona pętla w module erl_tar (Erlang OTP stdlib) oraz w kopiach tego kodu w hex_core, Hex i rebar3. Złośliwy archiwum tar z spreparowanym elementem GNU sparse powoduje, że proces rozpakowujący zapętla się bez końca, blokując jeden scheduler. Problem dotyczy OTP od 29.0 do 29.1.2, rebar3 od 3.27.1 do 3.28.0, stdlib od 8.0 do 8.1.1, hex od 2.4.2 do 2.5.3 oraz hex_core od 0.14.0 do 0.20.1.

W Erlang OTP ssl (moduły tls_handshake_1_3, ssl_handshake i tls_client_ticket_store) występuje nieprawidłowa walidacja spójności danych wejściowych. Złośliwy serwer TLS 1.3 może spowodować odmowę usługi aplikacji ssl na węźle klienta poprzez wysłanie wiadomości NewSessionTicket z nieprawidłowymi rozszerzeniami.

Obejście limitu szybkości uwierzytelniania w Zimbra Collaboration Suite 10.1.0 do 10.1.21 pozwala nieuwierzytelnionym atakującym na wielokrotne próby zgadywania hasła przez GraphQL bez zwiększania licznika niepowodzeń dla źródłowego adresu IP.

Podatność wstrzyknięcia filtra LDAP w Zimbra Collaboration Suite w wersjach od 10.1.0 do 10.1.21 pozwala nieuwierzytelnionym atakującym modyfikować zewnętrzne filtry wyszukiwania LDAP. W domenach korzystających z uwierzytelniania opartego na filtrach wyszukiwania i leniwego provisioningu tworzy to oracle haseł dla użytkowników zewnętrznego katalogu. Uwierzytelnione wyszukiwania S/MIME mogą również zwracać certyfikaty i dane tożsamości dla nieprzewidzianych wpisów katalogowych.

F´ (F Prime) przed wersją 4.3.0 ma podatność w Svc::FileUplink, gdzie ścieżka docelowa z pakietu StartPacket jest kopiowana i otwierana do zapisu bez kanonizacji lub ograniczenia do katalogu uploadu. Pozwala to na tworzenie lub nadpisywanie plików w wybranych lokalizacjach.

F´ (F Prime) przed wersją 4.2.0 ma podatność w Svc::Ccsds::SpacePacketDeframer, gdzie handler traktuje minimalną długość pakietu jako FW_ASSERT zamiast odrzucać bufor. Gdy ramka telekomendy pozostawia sześć lub mniej bajtów, asercja powoduje przerwanie lub reset procesu, prowadząc do odmowy usługi.

W DPDK lib/vhost wykryto usterkę, w której gość może zdesynchronizować rozmiar virtqueue z rozmiarem tablicy deskryptorów inflight, powodując zapis poza zakresem w procesie vhost na hoście.

W DPDK lib/vhost wykryto błąd podwójnego przesunięcia w obliczeniach mapowania logów vhost, co może prowadzić do nieprawidłowego dostępu do pamięci.

W DPDK lib/vhost wykryto podatność TOCTOU (time-of-check to time-of-use) z podwójnym pobraniem deskryptorów kolejki kontrolnej, co pozwala na przepełnienie bufora sterty z kontrolowaną przez atakującego zawartością w handlerze VDUSE control-queue.

W Talos Linux w wersjach przed 1.12.9 i 1.13.3 narzędzie talosctl dołącza do generowanych paczek wsparcia pole auth z resources/registryconfigs.cri.talos.dev.yaml oraz wrażliwe dane z etcfilespecs.files.talos.dev.yaml, zamiast je oznaczyć lub zredagować. Udostępnienie takiej paczki niepowołanej osobie może ujawnić prywatne dane uwierzytelniające do rejestru. Problem naprawiono w wersjach 1.12.9 i 1.13.3.

KEDA to komponent autoskalowania oparty na Kubernetes. W wersji 2.20.2 i wcześniejszych administrator przestrzeni nazw, który może tworzyć zasoby TriggerAuthentication i ScaledObject, może ustawić hashiCorpVault.address na punkt końcowy kontrolowany przez najemcę i wybrać uwierzytelnianie Kubernetes bez jawnego poświadczenia. KEDA używa wtedy tokenu ServiceAccount operatora i wysyła go do tego punktu końcowego jako poświadczenie logowania do Vault; filtr kształtu JWT z wcześniejszej poprawki CVE-2025-68476 akceptuje token operatora, ponieważ jego podmiotem jest ServiceAccount Kubernetes, co pozwala atakującemu uzyskać uprawnienia operatora w całym klastrze, w tym szeroki odczyt Secretów oraz operacje na obciążeniach lub związane z admission.