CVE-2026-109960

Froxlor przed wersją 2.3.14 zawiera podatność typu insecure direct object reference w edytorze szablonów e-mail (admin_templates.php), ponieważ treść wiadomości pobierana jest przez mailbodyid bez sprawdzenia właściciela (adminid). Uwierzytelnieni administratorzy reseller mogą łączyć własny subjectid z obcymi, sekwencyjnymi wartościami mailbodyid, aby odczytać szablony e-mail innych administratorów, w tym pełnego administratora.

Froxlor w wersji od 0.10.0 do 2.3.14 zawiera podatność braku autoryzacji, która pozwala kontom resellerów na odczyt konfiguracji serwera MySQL i zadań cron przeznaczonych tylko dla pełnego administratora poprzez polecenia API. Resellerzy mogą wywołać MysqlServer.listing, MysqlServer.get lub Cronjobs.listing przez api.php, aby uzyskać nazwy użytkowników zarządzających, hosty, porty, ustawienia TLS i metadane cron.

Froxlor w wersjach od 0.10.0 do 2.3.14 zawiera podatność wstrzykiwania nowej linii, która pozwala uwierzytelnionym klientom na wstrzyknięcie dowolnych wpisów do bazy danych grup NSS należącej do roota poprzez niezwalidowany parametr additional_members w API Ftps.add. Atakujący mogą osadzić znaki nowej linii, które cron REBUILD_NSSUSERS zapisuje bez sanityzacji do /var/lib/extrausers/group, tworząc uprzywilejowane wpisy grupowe dla lokalnej eskalacji uprawnień.

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 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 2.3.10 i wcześniejszych zawiera niekompletną poprawkę podatności GHSA-75h4-... — cron eksportu danych klienta (DataDump) nie waliduje pośrednich komponentów ścieżki docelowej. Funkcja Froxlor\FileDir::makeCorrectDir() ma błąd off-by-one w przechodzeniu komponentów ścieżki, pomijając pierwszy segment poniżej katalogu domowego klienta, a zabezpieczenie w ExportCron.php sprawdza tylko ostatni komponent przez is_link(). Uwierzytelniony klient z włączonym eksportem może zaplanować eksport do podkatalogu swojego webspace, a następnie zastąpić pośredni komponent ścieżki dowiązaniem symbolicznym przed uruchomieniem crona jako root. Wtedy 'chown -R' rekurencyjnie zmienia właściciela drzewa katalogów (np. /etc) na UID klienta, co prowadzi do przejęcia uprawnień roota i kompromitacji między dzierżawcami.

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.

Froxlor w wersjach przed 2.3.12 nie ogranicza ani nie escapuje ustawienia system.letsencryptchallengepath — w przeciwieństwie do innych ustawień wzmocnionych w GHSA-33mp, pole nie ma zabezpieczenia string_regexp ani required_otp, a jego wartość jest dołączana bez escapowania do wiersza poleceń acme.sh budowanego w lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php i wykonywanego przez cron roota przez FileDir::safe_exec. Ponieważ safe_exec blokuje tylko metaznaki powłoki takie jak ; | & > < \ $ ~ ?, spacje i cudzysłowy przechodzą, a wartość jest dzielona na dodatkowe argumenty acme.sh. Administrator lub dowolny podmiot mogący zapisywać ustawienia (np. przez API importu ustawień) może wstrzyknąć opcje acme.sh takie jak --renew-hook, --pre-hook lub --post-hook, aby uzyskać wykonanie dowolnych poleceń jako root przy następnym uruchomieniu crona Let's Encrypt, albo użyć --config-home/--cert-home do zapisu dowolnych plików.