CVE-2026-100716

Froxlor 2.0.0 do 2.3.10 jest podatny na przechowywany cross-site scripting. Gdy klient (najniżej uprzywilejowana rola) przesyła certyfikat SSL dla własnej domeny, metody add()/update() API Certificates parsują go funkcją openssl_x509_parse() i przechowują wartość issuer organization bez sanityzacji. Renderer tabel Froxlor emituje komórki skalarne przez filtr `raw` Twig, wyłączając automatyczne escapowanie HTML, więc gdy administrator lub reseller otworzy Domeny > Certyfikaty SSL, wartość issuer dostarczona przez atakującego wykonuje się jako skrypt w sesji uprzywilejowanego użytkownika. Problem przekracza granicę uprawnień od klienta do administratora i może prowadzić do pełnego przejęcia konta administratora; ponieważ administrator Froxlor kontroluje serwer WWW, DNS i konfigurację PHP stosowaną przez cron działający jako root, problem może być dalej eskalowany do wykonania poleceń jako root na zarządzanym serwerze. Problem naprawiono w Froxlor 2.3.12.

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 nie egzekwuje polityki mail.allow_external_domains w poleceniu API EmailSender.add. Gdy administrator włączył funkcję dozwolonych nadawców, ale wyłączył zewnętrzne domeny (mail.enable_allow_sender = 1, mail.allow_external_domains = 0), uwierzytelniony klient z dostępem do API może nadal użyć EmailSender.add do zarejestrowania dowolnego zewnętrznego adresu nadawcy dla swojej skrzynki, który jest przechowywany mimo polityki. Tworzy to obejście między konfiguracją UI/administratora a API i — tam gdzie wygenerowana konfiguracja poczty korzysta z tabeli dozwolonych nadawców — umożliwia klientowi autoryzację tożsamości nadawcy spoza hostowanych domen, ułatwiając podszywanie się pod nadawcę. Naprawiono w wersji 2.3.12.

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 przed wersją 2.3.12 nie unieważnia istniejących sesji panelu, kluczy API i ciasteczek zaufania 2FA po zmianie hasła użytkownika. Atakujący posiadający przejęte sesje, ważne klucze API lub tokeny zaufania 2FA zachowują pełny dostęp do konta po rotacji hasła, omijając działania związane z reagowaniem na incydenty.

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.

Froxlor do wersji 2.3.10 przechowuje tylko numeryczny identyfikator użytkownika w tokenach zapamiętanych 2FA (panel_2fa_tokens) bez rejestrowania przestrzeni nazw konta, a wyszukiwanie zapamiętanego tokena podczas logowania nie jest ograniczone do typu konta klienta lub administratora. Ponieważ identyfikatory klientów i administratorów są przydzielane z oddzielnych przestrzeni nazw, token zapamiętany 2FA wydany klientowi o danym ID pasuje również do administratora o tym samym ID. Atakujący kontrolujący konto klienta z kolidującym ID, posiadający ważne ciasteczko zapamiętane 2FA i znający hasło administratora, może ominąć drugi czynnik TOTP administratora i uzyskać uwierzytelnioną sesję administratora. Jest to tylko obejście drugiego czynnika; nie pokonuje uwierzytelniania hasłem. Naprawiono w wersji 2.3.12.

Froxlor przed wersją 2.3.13 zwraca kolumnę ssl_key_file — która przechowuje surową zawartość prywatnego klucza TLS w formacie PEM — bezpośrednio w odpowiedziach JSON poleceń API Certificates.get i Certificates.listing, ponieważ wyniki zapytań domain_ssl_settings są przekazywane przez ApiCommand::response() bez żadnego usuwania pól ani listy dozwolonych. Nisko uprzywilejowany uwierzytelniony klient API może pobrać klucze prywatne certyfikatów swoich domen, w tym klucze Let's Encrypt generowane przez Froxlor po stronie serwera i przechowywane z uprawnieniami root-only (0600), do których klient nie ma dostępu do systemu plików; konta reseller i customers_see_all admin mogą zrzucić klucze prywatne innych podmiotów przez ten sam mechanizm. Ujawnione klucze umożliwiają podszywanie się pod domenę, pasywne deszyfrowanie przechwyconego ruchu TLS oraz aktywne ataki typu man-in-the-middle.

Froxlor w wersjach 2.3.10 i wcześniejszych zawiera niekompletną poprawkę podatności GHSA-c3p2 — funkcja Validate::validateUrl odrzuca znaki CR/LF tylko w ścieżce, zapytaniu i fragmencie, a nie sprawdza części userinfo (user:pass@). Uwierzytelniony klient z uprawnieniami do tworzenia subdomen może podać adres URL przekierowania subdomeny z ładunkiem CR/LF w części userinfo, który przechodzi walidację i jest zapisywany dosłownie w konfiguracji vhost nginx lub Apache. Froxlor regeneruje i przeładowuje konfigurację jako root, więc wstrzyknięte dyrektywy działają w całym serwerze.

Froxlor w wersjach do 2.3.10 jest podatny na dowolne usuwanie plików poprzez podążanie za dowiązaniami symbolicznymi w zadaniu cron usuwania danych FTP. Zadanie cron 8 (deleteFtpData), kolejkowane przy usuwaniu konta FTP, wywołuje FileDir::makeCorrectDir() bez argumentu $fixed_homedir, więc przechodzenie komponentów ścieżki jest pomijane, a następnie wykonuje 'rm -rf' jako root na wynikowej ścieżce z jedynie tekstowymi zabezpieczeniami. Ponieważ makeCorrectDir() dodaje końcowy ukośnik, GNU rm podąża za dowiązaniem symbolicznym użytym jako pośredni lub końcowy komponent ścieżki. Uwierzytelniony klient mogący zapisywać w katalogu domowym FTP może umieścić dowiązanie symboliczne między wstawieniem zadania a wykonaniem crona, powodując rekurencyjne usunięcie dowolnych drzew katalogów przez zadanie roota.