Krytyczny błąd w Rejetto HFS już atakowany

Krytyczna luka w Rejetto HFS pod ostrzałem

W Rejetto HTTP File Server (HFS) wykryto podatność, która może prowadzić do pełnego przejęcia serwera. Problem jest poważny, bo atakujący nie musi się uwierzytelnić, aby wykorzystać błąd i zyskać dostęp administratora.

Luka oznaczona jako CVE-2026-61500 dotyczy wersji od 3.0.0 do 3.2.0 i została załatana w HFS 3.2.1. Z publicznie dostępnych informacji wynika, że podatność jest już aktywnie wykorzystywana w realnych atakach.

Na czym polega problem

Sedno błędu tkwi w sposobie generowania klucza podpisującego cookies sesyjne. Zamiast bezpiecznego generatora kryptograficznego użyto Math.random(), czyli mechanizmu, który nie nadaje się do zastosowań bezpieczeństwa.

Dodatkowo proces logowania ujawnia część informacji pozwalających odtworzyć stan generatora. W praktyce oznacza to, że napastnik może:

1. zebrać kilka odpowiedzi z procesu logowania,
2. odtworzyć stan PRNG,
3. odzyskać klucz podpisu sesji,
4. sfałszować cookie administratora,
5. uzyskać dostęp do funkcji prowadzących do RCE.

Kluczowe znaczenie ma tu funkcja server_code, która pozwala wykonywać JavaScript po stronie serwera. Po przejęciu sesji administratora atakujący może więc przejść od obejścia logowania do uruchamiania własnego kodu na serwerze.

Skala zagrożenia i pierwsze ataki

Podatność oceniono bardzo wysoko: CVSS 4.0: 9.3 oraz CVSS 3.1: 9.8. To poziom odpowiadający zagrożeniu krytycznemu.

W końcówce września pojawił się publiczny PoC w Pythonie, co wyraźnie obniżyło próg wejścia dla kolejnych napastników. Następnego dnia po ujawnieniu dodatkowych szczegółów zaczęto obserwować próby exploitacji wobec rzeczywistych hostów wystawionych do internetu, między innymi w Stanach Zjednoczonych. Zidentyfikowano też aktywność przypisywaną nieznanemu podmiotowi z Chin.

W ocenie obserwatorów działania miały na razie charakter ograniczonego rozpoznania, ale sam fakt pojawienia się prób ataków tak szybko po publikacji szczegółów pokazuje, jak łatwo taka luka może zostać skomercjalizowana lub użyta w masowych kampaniach.

Co powinni zrobić administratorzy

Najważniejszy krok to natychmiastowa aktualizacja do Rejetto HFS 3.2.1 lub nowszej. W przypadku serwerów publicznie dostępnych nie warto zwlekać, zwłaszcza jeśli infrastruktura używa wersji z zakresu 3.0.0–3.2.0.

Warto też:

• sprawdzić, które instancje HFS są wystawione do internetu,
• zweryfikować dokładne wersje oprogramowania,
• ograniczyć dostęp do panelu administracyjnego i API tylko do zaufanych sieci,
• przejrzeć logi pod kątem nadużyć związanych z logowaniem i wywołań get_config oraz set_config,
• w razie podejrzenia incydentu zrotować hasła i sprawdzić integralność systemu.

Jako środek tymczasowy można rozważyć użycie silnych kluczy podpisu w COOKIE_SIGN_KEYS, ale nie jest to substytut poprawki. Jeśli serwer został już przejęty, samo załatanie luki nie wystarczy.

Dlaczego ten przypadek jest groźny

To kolejny przykład, jak błąd w pozornie prostym elemencie — tutaj w mechanizmie sesji — może otworzyć drogę do pełnego przejęcia systemu. W przypadku HFS konsekwencje są szczególnie dotkliwe, bo od sfabrykowanej sesji administratora do zdalnego wykonania kodu prowadzi już bardzo krótka ścieżka.

Organizacje korzystające z HFS powinny potraktować tę podatność priorytetowo, zwłaszcza jeśli serwer jest publicznie dostępny lub pełni ważną rolę w wymianie plików.