Konferencja Mega Sekurak Hacking Party w Krakowie – 26-27 października!
Problemy z walidacją nazw plików umożliwiały RCE i patch bypass w narzędziu FreeScout
W aplikacji FreeScout odkryto podatność Remote Code Execution (RCE). Dzięki możliwości wgrania na serwer pliku .htaccess, a następnie pliku tekstowego (który przekazywany był do interpretera PHP) możliwe było wykonanie dowolnego kodu na serwerze. Podatność otrzymała numer CVE-2026-27636.
TLDR:
- W aplikacji FreeScout wykryto podatność RCE (CVE-2026-27636) umożliwiającą wykonanie dowolnego kodu na serwerze.
- Atak polegał na wgraniu pliku .htaccess, który wymuszał interpretowanie plików .txt jako kodu PHP. Niezbędne było posiadanie konta na podatnej instancji FreeScout.
- Pierwsza poprawka (blokowanie dotfiles) została ominięta poprzez użycie znaku zero-width space w nazwie pliku.
- Ostateczne rozwiązanie polega na zmianie kolejności walidacji i sanityzacji nazw plików. Administratorzy powinni zaktualizować FreeScout do wersji 1.8.207 lub nowszej.
FreeScout to otwartoźródłowe, samodzielnie hostowane narzędzie do obsługi zgłoszeń (ticketów) i współdzielonej (np. w ramach zespołu helpdesk) skrzynki pocztowej. Aplikacja została stworzona w języku PHP (framework Laravel) i zdobyła ponad 4 tys. gwiazdek na GitHubie.
Do wykorzystania podatności niezbędne jest posiadanie konta na atakowanej instancji FreeScout. Znacznie ogranicza to ryzyko dla administratorów, choć skutki wykorzystania podatności mogą być naprawdę poważne.
Użytkownik ma możliwość wysłania nowej wiadomości (w ramach zarządzanej przez FreeScout skrzynki e-mail) w panelu. Podczas tworzenia takiej wiadomości możliwe jest także dodawanie załączników. Co ciekawe, załączniki są zapisywane w systemie plików jeszcze przed wysłaniem wiadomości e-mail. Oznacza to, że nie trzeba nawet wysyłać wiadomości (co pozostawia ślad w historii konwersacji) by wgrać na serwer własne pliki.
Nie jest oczywiście możliwe wgranie pliku PHP, natomiast serwer nie blokuje wgrywania plików .htaccess (konfiguracja dla serwera Apache). Badacze z OX Security przetestowali więc zachowanie aplikacji przesyłając konfigurację, która nakazywała traktowanie plików .txt jako wykonywalnego kodu PHP
Drugim plikiem był webshell.txt, który był “zwykłym” kodem PHP, tylko zapisano go jako plik tekstowy.
Po wgraniu plików w panelu możliwe jest ich wyświetlenie w kontekście FreeScout (są dostępne pod ścieżką /storage/attachment). Otwarcie w taki sposób pliku webshell.txt powodowało wykonanie kodu PHP tak jak przy standardowym pliku .php.
Umieszczona w kodzie funkcja shell_exec pozwalała na wykonanie dowolnego polecenia (w tym przypadku wskazywanego w parametrze cmd adresu URL) na serwerze, na którym hostowana była instancja FreeScout.
Oczywiście dotyczy to tylko instancji, które wykorzystują serwer Apache oraz ewentualnie moduły implementujące wsparcie dla .htaccess na innych serwerach. Wykorzystanie takiej podatności umożliwia przejęcie kontroli nad serwerem, w tym uzyskanie dostępu do danych z wszystkich ticketów FreeScout, zawartości skrzynki pocztowej oraz (zależnie od konfiguracji środowiska) innych usług hostowanych na tej samej maszynie.
W reakcji na tę podatność, twórcy FreeScout dodali blacklistę plików, które nie mogą być wgrane z poziomu panelu – od tego momentu niemożliwe było wysłanie zarówno .htaccess, jak i .user.ini (plik konfiguracyjny dla języka PHP). Nie było to jednak pełne rozwiązanie problemu, ponieważ w zależności od środowiska (FreeScout działa w modelu self-hosted), potencjalnie możliwe jest także wsparcie dla różnych innych plików konfiguracyjnych.
W ostatecznej poprawce wprowadzono bardziej ogólną regułę – niemożliwe jest wgrywanie plików, których nazwy zaczynają się od kropki (dotfiles). W takich plikach przechowywane są wartości konfiguracyjne środowisk, repozytoriów i innych narzędzi.
Jednak i to okazało się nie rozwiązywać problemu. Badacze z OX Security odkryli kolejną podatność – “patch bypass” (CVE-2026-28289), która polegała na możliwości ominięcia walidacji przez przesłanie pliku .htaccess z prefiksem w postaci znaku zero-width space.
Choć znak ten nie jest widoczny w nazwie, taki plik można wgrać jako załącznik (w ramach walidacji sprawdzane jest, czy nazwa zaczyna się od kropki). Na pierwszy rzut oka nie jest to nic niebezpiecznego, bo nazwany w taki sposób plik nie zostanie potraktowany jak konfiguracja.
Problemem jest jednak sanityzacja. Po sprawdzeniu nazwy, znak zero-width space zostaje usunięty, a plik trafia na dysk pod nazwą .htaccess.
Wystarczy więc dodać jeden znak do nazwy, aby przejąć kontrolę nad serwerem, na którym uruchomiono aplikację. W tym przypadku poprawka polegała na zamianie kolejności – sanityzacja wykonywana jest przed walidacją, a więc plik .htaccess z zero-width space i tak zostanie odrzucony z powodu nazwy zaczynającej się od kropki.
Administratorom korzystającym z FreeScout polecamy zaktualizować instancje do wersji v1.8.207 lub nowszej. To wyeliminuje zarówno pierwotną podatność, jak i możliwość ominięcia pierwszej poprawki. W przypadku tej podatności pomogłoby również wyłączenie AllowOverride w konfiguracji Apache, jednak jest to tylko częściowe rozwiązanie.
W tym przypadku do wykorzystania podatności niezbędne było posiadanie konta na instancji FreeScout, ale wcale nie musimy zakładać złej woli któregoś z użytkowników. Możliwe jest także, że czyjeś konto zostanie przejęte. Przy wystawianiu własnych usług / narzędzi self-hosted, rekomendujemy więc rozważyć również:
- schowanie usług, które nie muszą być dostępne z zewnątrz (np. wewnętrzne narzędzia w organizacji) za VPN-em;
- ograniczanie uprawnień użytkowników do koniecznego minimum (w ramach podejścia Zero Trust);
- usuwanie wszelkich niepotrzebnych dostępów (np. wycofywanie “starych” uprawnień pracownikowi, który przenosi się do innego działu/zespołu w organizacji).
Źródła:
~Tymoteusz Jóźwiak
