Katalog podatności CVE

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.

Adminer 4.16.0 do 6.0.1 zawiera podatność SSRF przed uwierzytelnieniem w opcjonalnym sterowniku Elasticsearch (plugins/drivers/elastic.php), naprawioną w 6.0.2. Ponieważ adminer/include/auth.inc.php wywołuje Driver::connect() przed walidacją wyniku logowania, nieuwierzytelniony atakujący może wysłać spreparowane parametry auth[server], auth[username] i auth[password], powodując, że serwer Adminer wyśle żądanie HTTP GET do dowolnego osiągalnego hosta i portu. Sterownik nie blokuje adresów loopback, prywatnych, link-local ani innych zastrzeżonych; jeśli nie podano portu, dodaje domyślny 9200, a ogólna kontrola portów odrzuca porty poniżej 1024. Wybrane pola błędów JSON z odpowiedzi innych niż 2xx oraz błędy połączenia są renderowane na stronie logowania, co umożliwia skanowanie portów i rozpoznanie wewnętrznej sieci. Wymaga to wdrożenia opcjonalnego sterownika Elasticsearch i włączenia allow_url_fopen.

Adminer przed wersją 6.0.2 zawiera podatność cross-site scripting, gdzie wynik CONNECTION_ID() z bazy danych jest interpolowany do JavaScript bez odpowiedniego escapowania, co pozwala złośliwemu serwerowi bazy danych na wykonanie dowolnego JavaScript w uwierzytelnionym kontekście Adminer. W środowiskach współlokowanych, gdzie baza danych ma uprawnienia FILE i może zapisywać do katalogu głównego WWW, atakujący mogą użyć XSS do wysyłania uwierzytelnionych żądań SQL, które zapisują pliki PHP przez INTO DUMPFILE, osiągając zdalne wykonanie kodu jako konto serwera WWW.

Hugo, generator stron statycznych, w wersjach od v0.56.0 do v0.165.x renderuje pliki treści o typie media text/org bez escapowania surowego HTML. Bloki eksportu Org oraz fragmenty @@html:...@@ przepuszczają HTML bez escapowania, co prowadzi do cross-site scripting (XSS) w generowanej witrynie. Luka dotyczy tylko stron, których plik źródłowy lub wynik adaptera treści deklaruje typ text/org; wersja v0.166.0 naprawia problem, wprowadzając allowlistę security.allowContent, która domyślnie blokuje text/org.

Hugo w wersjach od 0.75.0 do 0.165.x zawiera podatność typu stored cross-site scripting: highlighter składni nie escapuje opcji lineAnchors przed przekazaniem jej do Chromy, który zapisuje wartość dosłownie w atrybutach id i href generowanego znacznika numerów linii. Spreparowana wartość lineAnchors podana jako atrybut bloku kodu Markdown (lub przekazana do funkcji szablonu highlight) skutkuje nieescapowanym HTML w renderowanej stronie, co pozwala na wykonanie dowolnego JavaScriptu w przeglądarkach odwiedzających. Luka naprawiona w 0.166.0 poprzez escapowanie HTML wartości lineAnchors przed przekazaniem do Chromy.

GitPython przed wersją 3.1.62 nie waliduje pola path odczytywanego z niezaufanego pliku .gitmodules podczas aktualizacji submodułów. Podczas gdy wcześniejsza poprawka (GHSA-hmq2-w58f-27jc) dodała Submodule._validated_name() ograniczające pole name, a wewnętrzny mechanizm ochrony Submodule._to_relative_path() jest stosowany w add() i move(), metoda Submodule.update() wyznacza bezwzględną lokalizację checkout z surowej wartości path bez tej ochrony. Wpis .gitmodules zawierający komponenty przejścia katalogowego (np. path = ../../../tmp/escaped) może spowodować tworzenie katalogów przez os.makedirs() poza drzewem roboczym repozytorium, wypełnienie ich z URL submodułu oraz usunięcie przez shutil.rmtree() przy użyciu force_remove. Luka naprawiona w GitPython 3.1.62.

Budibase server przed wersją 3.45.0 zawiera podatność cross-tenant information disclosure w endpoincie GET /api/applications/:appId/appPackage, która pozwala uwierzytelnionym użytkownikom odczytać metadane aplikacji i kod źródłowy innego tenanta. Atakujący może podać identyfikator aplikacji ofiary, aby bez kontroli autoryzacji uzyskać wrażliwe szczegóły aplikacji, w tym strukturę nawigacji, nazwy ról, wewnętrzne adresy URL ekranów, fragmenty JavaScript i identyfikatory użytkowników.

Budibase Server przed wersją 3.45.0 nie redaguje jawnych poświadczeń źródeł danych przed rozgłaszaniem aktualizacji tabel zewnętrznych do pokoju websocket współpracy Builder. Atakujący z dostępem do Builder mogą przechwycić nieocenzurowane obiekty źródeł danych zawierające hasła do baz danych i klucze API, obserwując operacje zapisu lub usunięcia tabeli.

Budibase przed wersją 3.45.0 zawiera nieuwierzytelnioną podatność server-side request forgery i eksfiltracji poświadczeń w endpoincie webhook Microsoft Teams, który przyjmuje sfałszowane aktywności Bot Framework z dowolnymi wartościami serviceUrl. Atakujący może wysłać spreparowane żądanie POST, aby wstrzyknąć kontrolowany przez siebie serviceUrl, który jest utrwalany i używany do wszystkich kolejnych odpowiedzi bota, powodując wysyłanie aktywnych tokenów dostępu Microsoft OAuth w nagłówkach Authorization do hosta atakującego oraz umożliwiając ślepy dostęp do sieci wewnętrznej.

Wersje stoatchat przed 0.15.5 nie egzekwują limitów prób na poziomie konta przy wyzwaniach MFA podczas logowania, ograniczając się jedynie do limitu opartego na adresie IP. Atakujący znający hasło może odgadywać kody TOTP, ponownie wykorzystując bilety wyzwania MFA i rozkładając próby na wiele adresów IP, aby obejść ograniczenia i uzyskać dostęp do konta.

Wersje stoatchat przed 0.15.5 zawierają podatność umożliwiającą enumerację kont w punkcie końcowym logowania, ujawniającą lokalizacje plików źródłowych w odpowiedziach błędów. Nieuwierzytelniony atakujący może rozróżnić zarejestrowane i niezarejestrowane adresy e-mail, porównując pola lokalizacji błędów zwracane z żądań POST /api/auth/session/login.

Wersje stoatchat przed 0.15.5 zawierają podatność typu denial of service w workerze potwierdzeń przetwarzającym wiadomości z masowymi wzmiankami. Uwierzytelniony użytkownik może wysłać pięć spreparowanych wiadomości z wzmiankami ról, aby zakończyć wszystkie workery potwierdzeń, wyłączając powiadomienia push i odznaki wzmianek w całym wdrożeniu do czasu restartu procesu API.

Wersje stoatchat przed 0.15.5 nie ponownie walidują nazw użytkowników po sanityzacji Unicode, umożliwiając atakującym tworzenie nazw z zabronionymi znakami poprzez podanie liter Unicode, które przekształcają się w odrzucone znaki. Atakujący mogą obejść listy dozwolonych znaków i limity długości, tworząc nazwy łudząco podobne do zarezerwowanych, osadzając znaki specjalne i przekraczając limit 32 znaków.

Grav 2.0.0 do 2.0.24 zawiera lukę w sandboxie Twig, która pozwala na ominięcie zabezpieczeń. Filtr `array` jest dozwolony w sandboxie, ale nie sprawdza listy dozwolonych metod, co umożliwia odczytanie prywatnych danych kontenera DI, w tym pełnej konfiguracji z sekretami (hasła, klucze OAuth, SMTP, Redis, proxy).

grav-plugin-login (wtyczka logowania do Grav CMS) w wersjach >= 3.8.7 i < 3.9.7 pozwala na ominięcie wyzwania dwuskładnikowego uwierzytelniania (2FA) dla treści chronionych funkcją Twig `authenticated()` lub shortcode `[authenticated]`. Na stronach z włączonym 2FA, `Login::isAuthenticated()` sprawdza tylko flagę sesji oznaczającą pomyślny krok hasła, a nie flagę oznaczającą pełne zalogowanie, więc sesja na etapie podawania kodu 2FA jest traktowana jako w pełni uwierzytelniona. Atakujący znający hasło członka, ale nie mogący odpowiedzieć na drugi czynnik, może czytać treści dostępne tylko dla członków.