Katalog podatności CVE

http4k (pakiet Maven org.http4k:http4k-core) przed wersjami 6.49.0.0, 5.42.0.0 i 4.51.0.0 używa domyślnie dopasowania podciągu (Contains) na nagłówku Host w funkcjach reverseProxy() i reverseProxyRouting() podczas kierowania do skonfigurowanych wirtualnych hostów. Jeśli te funkcje są wdrożone jako publiczny przychodzący handler HTTP z dwoma lub więcej skonfigurowanymi wirtualnymi hostami, zdalny atakujący może dostarczyć nagłówek Host, który jedynie zawiera skonfigurowaną nazwę vhost (np. Host: admin.evil.com dla vhost skonfigurowanego jako "admin") i zostać przekierowany do tego vhost, omijając autoryzację opartą na routingu.

vm2 przed wersją 3.12.2 nie stosuje obsługi odrzuceń Promise po stronie hosta w pułapce konstrukcji sandbox-host. W BaseHandler, pułapka apply wywołuje markHostPromiseHandled() na zwróconej wartości, ale sąsiednia ścieżka construct zwraca wynik Reflect.construct bez tej samej sanityzacji. Jeśli embedder udostępnia konstruowalną funkcję hosta, której konstruktor zwraca natywnie odrzuconą Promise, niezaufany skrypt uruchomiony przez VM.run może ją wywołać z `new` i zignorować wynik; odrzucona Promise hosta przechodzi przez most nieobsłużona i, zgodnie z rygorystyczną polityką nieobsłużonych odrzuceń Node, jest promowana do nieprzechwyconego wyjątku, który kończy proces hosta.

Contrast, środowisko uruchomieniowe Kubernetes dla poufnych kontenerów, przed wersją 1.12.1 ma podatność w funkcji bezpiecznych woluminów trwałych. Złośliwy host może dostarczyć spreparowany wolumin LUKS2 do poda VM. Metadane woluminu LUKS2 nie są uwierzytelniane, a w wersjach cryptsetup przed 2.8.1 nagłówek określający algorytm szyfrowania null keyslot (cipher_null-ecb) jest akceptowany bez błędu. Ponieważ Initializer Contrast zakłada, że urządzenie jest chronione, jeśli `cryptsetup open` zakończy się sukcesem z tajnym ziarnem, gość otworzy wolumin dostarczony przez atakującego i zapisze tajne dane w postaci jawnej lub pod kluczem znanym atakującemu, co pozwala hostowi odczytać poufne dane, które powinny być zaszyfrowane.

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Kibana może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Nieograniczone zużycie zasobów (CWE-400) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130).

Brak autoryzacji (CWE-862) w Kibana może prowadzić do nieautoryzowanego usuwania danych poprzez wykorzystanie niepoprawnie skonfigurowanych poziomów kontroli dostępu (CAPEC-180). Uwierzytelniony użytkownik z uprawnieniami Synthetics ograniczonymi do pojedynczej przestrzeni Kibana może trwale usunąć monitory Synthetics współdzielone z przestrzeniami, do których nie ma dostępu. W przypadku monitora powiązanego z prywatną lokalizacją ta sama operacja niszczy również konfigurację integracji Elastic Agent bez kontroli autoryzacji, które Fleet normalnie stosuje.

Podatność w Kibanie umożliwia obejście autoryzacji poprzez kontrolowany przez użytkownika klucz (CWE-639). Uwierzytelniony użytkownik z uprawnieniami do funkcji Timeline w przestrzeni Kibany może wyliczać, odczytywać, modyfikować i usuwać wersje robocze obiektów Timeline należących do innych użytkowników w tej samej przestrzeni. Do wyliczenia i ujawnienia wystarczy dostęp tylko do odczytu, a do modyfikacji i usunięcia wymagane jest uprawnienie zapisu do Timeline.

Podatność ujawnienia poświadczeń w Froxlor przed wersją 2.3.12 w komendzie API DirProtections.listing, która zwraca hashe haseł htpasswd. Uwierzytelnieni użytkownicy API mogą pobrać hashe bcrypt haseł użytkowników katalogów chronionych, co umożliwia ataki offline i ujawnienie ponownie użytych poświadczeń.

Froxlor do wersji 2.3.10 wyłącza dwuskładnikowe uwierzytelnianie (2FA) użytkownika natychmiast po nieuwierzytelnionym żądaniu GET do strony zarządzania 2FA (np. /customer_index.php?page=2fa&action=delete), bez potwierdzenia, ponownego uwierzytelnienia ani tokena CSRF. Globalny middleware CSRF obejmuje tylko żądania POST/PUT/PATCH/DELETE, a ciasteczko sesji ma SameSite=Lax, więc nawigacja między witrynami (kliknięcie linku lub przekierowanie) przenosi sesję ofiary i cicho czyści type_2fa/data_2fa. Dotyczy to zarówno handlerów 2FA klienta, jak i administratora. Atakujący, który zwabi zalogowanego użytkownika panelu do kliknięcia spreparowanego linku, redukuje konto do uwierzytelniania tylko hasłem, co można połączyć z przejętym hasłem do przejęcia konta. Naprawione w 2.3.12.

Froxlor do wersji 2.3.10 nie filtruje wrażliwych kolumn z odpowiedzi API: Domains::get(), Domains::listing(), SubDomains::get() oraz gałąź admina SubDomains::listing() wykonują SELECT z użyciem wildcard na tabeli panel_domains i zwracają wiersz bez modyfikacji, w tym pole panel_domains.dkim_privkey. Uwierzytelniony administrator niebędący superadminem z flagą customers_see_all może odczytać prywatne klucze DKIM domen innych dzierżawców przez Domains.get, Domains.listing, SubDomains.get lub SubDomains.listing, a jedno wywołanie listing ujawnia klucz każdej widocznej domeny. Ujawnione klucze pozwalają atakującemu podpisywać e-maile przechodzące weryfikację DKIM i wyrównanie DMARC dla dotkniętych domen. To następstwo niepełnej poprawki, która usunęła hasło i data_2fa, ale nie dkim_privkey. Problem naprawiony w 2.3.12.

Nodemailer przed wersją 10.0.2 nie spłaszcza poprawnie głęboko zagnieżdżonych tablic w polach odbiorców, takich jak to, cc i bcc, co pozwala atakującym spowodować wyczerpanie stosu. Atakujący może dostarczyć głęboko zagnieżdżoną tablicę JSON odbiorców, która wyzwala rekurencyjną konwersję Array.toString(), wyczerpując stos i kończąc proces Node.js.

Nodemailer w wersjach 5.0.0 do 10.0.1 używa globalnej pamięci podręcznej DNS, która jest kluczowana tylko przez host DNS, podczas gdy każdy wpis pamięci podręcznej przechowuje również specyficzny dla wywołującego serwer TLS (servername). Gdy dwa transporty direct TLS/SMTPS (secure: true) rozwiązują ten sam host nie-IP z różnymi wartościami tls.servername, servername pierwszego transportu jest zwracane przy trafieniu w pamięć podręczną i nadpisuje jawnie skonfigurowaną wartość drugiego transportu, więc Nodemailer wysyła błędną wartość SNI i waliduje certyfikat peera względem błędnej tożsamości. W usługach wielodostępnych lub bramkach SMTP z routingiem SNI, atakujący, który może zainicjować pamięć podręczną, może spowodować, że transport ofiary połączy się z wirtualnym hostem TLS atakującego i zaakceptuje certyfikat atakującego nawet przy rejectUnauthorized: true, ujawniając poświadczenia SMTP ofiary. Naprawione w 10.0.2.

Nodemailer to biblioteka do wysyłania e-maili w Node.js. W wersjach >= 9.1.0 i < 10.0.9 parser adresów (src/addressparser) błędnie obsługuje adresy, których część lokalna jest ciągiem w cudzysłowie i które są poprzedzone komentarzami RFC 5322, co pozwala na zachowanie końcowych atomów domeny oddzielonych komentarzami w znormalizowanym adresie. Na przykład wejście "user"@example.com(x)evil.com jest parsowane do wartości adresu '[email protected] evil.com', która zawiera dodatkowy tekst domeny kontrolowany przez atakującego, oddzielony spacją. Ta sparsowana wartość jest używana bez dalszej ścisłej walidacji odbiorcy podczas budowania koperty wiadomości (envelope.to w src/mime-node), więc nieprawidłowy/niejednoznaczny adres odbiorcy może zostać zaakceptowany i umieszczony w kopercie SMTP. Nie potwierdzono, czy skutkuje to dostarczeniem do niezamierzonego odbiorcy na prawdziwych serwerach SMTP. Problem jest wariantem problemu parsowania komentarzy RFC 5322 opisanego w GHSA-cc9r-2j5m-2m83, dotyczącym osobnej ścieżki kodu z cytowaną częścią lokalną. Wersja 10.0.9 zawiera poprawkę.

Adminer 5.5.1 do 6.0.1 nieprawidłowo parsuje ciąg 'server' logowania w funkcji host_port() w adminer/include/functions.inc.php. Grupa przechwytująca port wymaga czystych cyfr zakotwiczonych na końcu ciągu, więc każda wartość serwera z niedomagającym ogonem nie spełnia wyrażenia regularnego i wraca do zwrócenia całego ciągu jako hosta z pustym portem. Ponieważ ograniczenie uprzywilejowanych portów w adminer/include/auth.inc.php sprawdza tylko sparsowany port, kontrola jest pomijana, a klient mysqli/mysqlnd następnie ponownie parsuje host:port z ciągu hosta i otwiera połączenie TCP. Zdalny, nieuwierzytelniony atakujący, który może dotrzeć do strony logowania Adminer, może przesłać spreparowaną wartość, taką jak 127.0.0.1:80/x, aby serwer zainicjował połączenia TCP do dowolnych wewnętrznych hostów i uprzywilejowanych portów przed weryfikacją poświadczeń, umożliwiając SSRF i ślepe skanowanie portów wewnętrznych (odmowa połączenia vs. handshake vs. timeout działa jako wyrocznia żywotności). To regresja, która ponownie otwiera obejście naprawione w 5.5.0 (GHSA-58cq-mgw2-38m5). Naprawione w 6.0.2.