FortiWeb CVE-2026-24017: obejście limitu logowania

Fortinet opublikował 10 marca 2026 roku advisory dla CVE-2026-24017, podatności CVSS 7.3 w FortiWeb. Nieuwierzytelniony napastnik mógł przygotować żądania omijające mechanizm ograniczania prób logowania. To nie był bezpośredni bypass hasła: powodzenie ataku zależało od zasobów atakującego i siły hasła. Luka usuwała jednak kontrolę, która miała czynić zgadywanie nieopłacalnym.

Poprawki znajdują się w:

• FortiWeb 8.0.3 dla wersji 8.0.0–8.0.2,
• 7.6.6 dla 7.6.0–7.6.5,
• 7.4.11 dla 7.4.0–7.4.10,
• 7.2.12 dla 7.2.0–7.2.11,
• 7.0.12 dla 7.0.0–7.0.11.

FortiAppSec Cloud nie był podatny. W dniu publikacji producent oznaczał status eksploatacji jako „not exploited”.

Dlaczego panel urządzenia brzegowego wymaga priorytetu

FortiWeb stoi przed aplikacjami i ma dostęp do ruchu, certyfikatów oraz konfiguracji ochrony. Przejęcie konta administracyjnego może umożliwić wyłączenie reguł, podgląd danych i stworzenie trwałego dostępu. Nawet luka „tylko” zwiększająca tempo prób ma większy wpływ, gdy panel jest publiczny i chroniony słabym lub ponownie użytym hasłem.

Rate limiting nie jest substytutem MFA. Z kolei MFA nie usprawiedliwia publicznego panelu. Poprawny model łączy aktualizację, dostęp wyłącznie z sieci zarządzającej lub VPN, osobne konta administratorów, silne uwierzytelnianie i monitoring.

Co zrobić poza aktualizacją

Sprawdź ekspozycję panelu z zewnętrznej perspektywy i zamknij ją na ACL. Zmień hasła administracyjne, jeśli były krótkie, współdzielone lub użyte w innym systemie. Zweryfikuj konta, klucze API, ostatnie logowania i zmiany polityk WAF. Szukaj wielu nieudanych prób rozłożonych po adresach, nietypowych nagłówków oraz logowania zakończonego sukcesem po długiej serii błędów.

Nie polegaj na jednym progu per IP — rozproszony password spraying pozostaje pod limitem. Koreluj po nazwie konta, fingerprintach klienta, ASN-ie i czasie. Dla administratorów używaj allowlisty sieci oraz phishing-resistant MFA.

CVE-2026-24017 nie była krytyczna w CVSS i nie miała potwierdzonej eksploatacji, ale dotyczyła urządzenia na brzegu. To dobry przykład priorytetyzacji opartej na ekspozycji, którą opisujemy w procesie zarządzania podatnościami. Możemy zweryfikować wersje i publiczną powierzchnię bez prób łamania haseł.

Plan aktualizacji urządzenia brzegowego

Przed zmianą wykonaj zaszyfrowany backup konfiguracji, zapisz hash i sprawdź możliwość odtworzenia na zgodnej wersji. Zweryfikuj rekomendowaną ścieżkę upgrade, ponieważ przeskok między gałęziami może wymagać wersji pośredniej. W klastrze HA sprawdź kolejność nodów, synchronizację konfiguracji i zachowanie aktywnych sesji.

Po aktualizacji nie ograniczaj testu do zielonego statusu. Potwierdź wersję każdego członka klastra, działanie polityk, certyfikatów, health checks i logowania administracyjnego. Z zewnątrz upewnij się, że panel nie jest dostępny, a z sieci zarządzającej wykonaj kontrolowane błędne próby i sprawdź, czy limit działa.

Jak nie pomylić brute force z password spraying

Brute force testuje wiele haseł dla jednego konta i łatwo przekracza limit użytkownika. Password spraying próbuje jednego popularnego hasła na wielu kontach, pozostając poniżej progu. Credential stuffing używa par login–hasło z wcześniejszych wycieków. Detekcja musi agregować te trzy osie osobno.

Zbuduj alerty na:

• wiele kont z jednego fingerprintu lub ASN-u,
• jeden login z rozproszonych źródeł,
• wzrost błędów zakończony sukcesem,
• logowanie administratora poza oknem i bez poprzedzającego VPN,
• zmianę polityki WAF tuż po nowej sesji.

Mitygacja, gdy patch musi poczekać

Najlepszym obejściem jest całkowite usunięcie interfejsu administracyjnego z internetu. Allowlista jednego adresu biura może być zawodna przy pracy zdalnej, więc lepiej użyć zarządzanego VPN lub bastionu z silnym MFA. Dodatkowy reverse proxy może ograniczać tempo, lecz musi prawidłowo identyfikować klienta i nie ufać dowolnemu X-Forwarded-For.

Czy producent oznaczył aktywne ataki? W dniu advisory nie. Brak potwierdzenia nie jest dowodem braku prób, a urządzenia brzegowe warto poprawiać zanim exploit stanie się powszechny.

Weryfikacja bez niebezpiecznego brute force

Nie trzeba wysyłać tysięcy haseł. Najpierw ustal wersję, ekspozycję i konfigurację. W wydzielonym środowisku z kontem testowym wyślij niewielką, uzgodnioną serię błędnych logowań i sprawdź, czy mechanizm blokuje dalsze próby, a SOC otrzymuje alert. Test ma twardy limit i nie używa prawdziwych kont.

Zachowaj wynik jako dowód: wersję, czas, identyfikator polityki i zdarzenie w SIEM. Po patchu powtórz dokładnie tę samą sekwencję. Dzięki temu organizacja potwierdza nie tylko instalację pakietu, ale działanie kontroli, której dotyczyła podatność.

Właścicielem nie może być wyłącznie zespół sieci. IAM odpowiada za konta i MFA, SOC za detekcję, a platforma za upgrade oraz HA. Wspólny runbook zapobiega sytuacji, w której każdy widzi tylko swój fragment.

---

Źródła pierwotne: Fortinet PSIRT FG-IR-26-082, Fortinet Upgrade Path Tool.