FortiWeb CVE-2026-26035: losowy login i hasło mogą otworzyć panel

12 sierpnia 2026 roku Fortinet opublikował CVE-2026-26035, błąd niewłaściwego uwierzytelnienia w FortiWeb. Zdalny, nieuwierzytelniony napastnik może zalogować się do GUI lub CLI, używając losowej nazwy użytkownika i hasła. Nie chodzi więc o łamanie silnego hasła istniejącego administratora, lecz o sytuację, w której mechanizm weryfikacji akceptuje dane, które powinny zostać odrzucone.

Advisory Fortinet FG-IR-26-158 przypisuje luce 8,8 w CVSS 3.1 i wskazuje następujące podatne zakresy: FortiWeb 8.0.0–8.0.2, 7.6.0–7.6.6, 7.4.0–7.4.11, 7.2.0–7.2.12 oraz 7.0.0–7.0.12. Ocena CNA ma pierwszeństwo przed starszymi lub automatycznymi ocenami agregatorów. Administrator powinien przejść na wydanie spoza odpowiedniego zakresu zgodnie z oficjalną ścieżką aktualizacji, a nie zgadywać wspólny numer dla wszystkich gałęzi.

Dlaczego błąd w WAF ma duży promień rażenia

FortiWeb chroni aplikacje webowe i API, terminując lub analizując ruch, stosując polityki WAF, reguły bot mitigation, certyfikaty i konfigurację backendów. Panel administracyjny jest więc control plane’em stojącym przed wieloma usługami. Przejęcie sesji administracyjnej może potencjalnie pozwolić na zmianę reguł ochrony, routingu, integracji lub ustawień logowania — dokładny zakres zależy od roli uzyskanej w podatnym systemie.

Rekord CVE potwierdza możliwość wejścia do GUI lub CLI. Nie potwierdza każdej późniejszej czynności ani masowej kampanii. Ocena wpływu na certyfikaty, backendy i polityki jest wnioskiem wynikającym z funkcji urządzenia. Podczas komunikacji incydentu warto zachować to rozdzielenie, aby nie przeceniać źródeł, a jednocześnie nie bagatelizować kontroli nad WAF.

Najwyższy priorytet mają interfejsy zarządzania osiągalne z Internetu, sieci użytkowników, segmentu gościnnego albo szerokiego VPN. Panel dostępny wyłącznie z odseparowanej sieci administracyjnej ma mniejszą osiągalność, ale nadal wymaga aktualizacji: przejęty host administratora lub błędna reguła może ominąć założenie o zaufanym segmencie.

Jak sprawdzić rzeczywistą ekspozycję

Nie wystarczy spojrzeć na bieżący interfejs i stwierdzić, że adres prywatny nie jest publiczny. Sprawdź reguły NAT, reverse proxy, load balancery, tunele serwisowe, dostęp FortiManager lub innych narzędzi zarządzających, historyczne zmiany zapory i konfiguracje HA. W klastrze każda jednostka oraz interfejs out-of-band mogą mieć inny adres i regułę.

Inwentaryzacja powinna zawierać numer wersji, gałąź, rolę w HA, adresy zarządzające, listę dozwolonych źródeł, rodzaj uwierzytelnienia i ostatnią zmianę konfiguracji. Obraz w magazynie lub wyłączone urządzenie też trzeba oznaczyć, aby nie wróciło do produkcji z podatnym firmware.

Zweryfikuj ekspozycję z zewnętrznego punktu pomiarowego kontrolowanego przez organizację. Sam skan wewnętrzny nie pokaże publikacji od strony WAN. Nie próbuj jednak odtwarzać obejścia uwierzytelnienia na produkcji. Do ustalenia ryzyka wystarczy potwierdzenie wersji i osiągalności; test exploita może zmienić stan i utrudnić dochodzenie.

Działania na pierwsze godziny

1. Ogranicz dostęp do GUI i CLI do pojedynczych hostów administracyjnych lub dedykowanego VPN. Jeśli panel jest publiczny, usuń publikację przed dalszymi pracami.
2. Potwierdź wersję każdej jednostki, w tym węzła pasywnego, i dopasuj ją do zakresów z FG-IR-26-158.
3. Wykonaj chronioną kopię konfiguracji i logów zgodnie z procedurą producenta; nie przechowuj jej w publicznym udziale.
4. Zaktualizuj do wersji wskazanej przez Fortinet jako rozwiązanie dla konkretnej gałęzi i zastosuj wymagane pośrednie kroki upgrade path.
5. Potwierdź po restarcie wersję, stan HA, synchronizację polityk, certyfikaty, health checki backendów i działanie krytycznych aplikacji.
6. Przejrzyj konta, role, klucze API, konfigurację zaufanych hostów, reguły WAF, routing, certyfikaty i cele wysyłki logów.
7. Jeżeli interfejs był osiągalny z niezaufanej sieci, rozpocznij analizę incydentową oraz rotację sekretów po potwierdzeniu integralności urządzenia.

Aktualizacja klastra wymaga planu dostępności. Nie należy jednak pozostawiać aktywnego węzła podatnego tylko dlatego, że pasywny został już naprawiony. Po każdej zmianie sprawdź, który węzeł obsługuje panel i ruch. W razie braku natychmiastowego okna najpierw zastosuj twardą kontrolę sieciową spoza samego FortiWeb, aby napastnik po przejęciu urządzenia nie mógł jej usunąć.

Czego szukać w logach

Przejrzyj udane logowania do panelu i CLI, również te z nazwami użytkowników nieobecnymi w normalnym katalogu. Zwróć uwagę na nietypowe adresy źródłowe, godziny, user-agenty i sesje bez poprzedzających typowych kroków logowania. Porównaj logi lokalne z zewnętrznym syslogiem, SIEM, NetFlow i historią dostępu VPN.

Następnie poszukaj działań po uwierzytelnieniu: nowych kont, zmian ról, eksportu konfiguracji, modyfikacji polityk, wyłączenia logowania, dodania certyfikatu, zmiany backendu lub reguł routingu. Te działania nie są dowodem wykorzystania konkretnego CVE; są śladami możliwego wpływu po uzyskaniu panelu. Korelacja czasu i sesji pozwala odróżnić administratora od nieznanej aktywności.

Brak zdarzenia w lokalnym logu nie dowodzi bezpieczeństwa. Osoba z wysokimi prawami może zmienić ustawienia logowania lub usunąć dane. Zewnętrzny kolektor powinien przyjmować zdarzenia jednokierunkowo, a urządzenie nie powinno móc ich nadpisywać. Jeżeli nie było takiej telemetrii, poziom pewności trzeba uczciwie oznaczyć jako niższy.

Sekrety i przywracanie zaufania

Po potwierdzonym lub prawdopodobnym przejęciu warto założyć, że dane dostępne dla roli administratora mogły zostać odczytane. Zakres rotacji ustala się z konfiguracji: konta lokalne, tokeny API, poświadczenia integracji, klucze prywatne certyfikatów, sekrety do backendów i systemów logujących. Nie każdy FortiWeb przechowuje je w tej samej formie, więc lista musi wynikać z konkretnej instalacji.

Rotuj po usunięciu podatności i ewentualnej trwałości. Dla certyfikatu rozważ nie tylko zmianę hasła, ale wydanie nowej pary kluczy, jeżeli prywatny klucz mógł być eksportowany. Sprawdź też logi aplikacji stojących za WAF: zmiana polityki mogła stworzyć krótkie okno, w którym złośliwy ruch dotarł do backendu.

W środowisku o wysokiej krytyczności przywrócenie z zaufanego obrazu i ręczne odtworzenie zatwierdzonej konfiguracji może dać większą pewność niż kontynuowanie pracy na urządzeniu o nieznanej integralności. Decyzję trzeba skoordynować z ciągłością działania, ale dostępność nie może oznaczać trwałego zaakceptowania przejętego control plane’u.

Długoterminowa architektura panelu

Panel WAF powinien być niewidoczny z Internetu, chroniony przez oddzielną bramę tożsamości i MFA, ograniczony sieciowo oraz obsługiwany z zarządzanych stacji. Konta osobiste są lepsze niż współdzielony administrator, ponieważ umożliwiają przypisanie zdarzeń. Dostęp awaryjny wymaga procedury, rejestrowania i automatycznego wygaśnięcia.

Aktualizacje urządzeń brzegowych powinny mieć krótszy SLA niż systemy wewnętrzne. Warto automatycznie porównywać wersje z PSIRT producenta, testować konfigurację na reprezentatywnym węźle i utrzymywać aktualny diagram ścieżek zarządzania. Control plane musi mieć niezależne logi oraz zewnętrzną kontrolę dostępu, której sam nie może wyłączyć.

Zakresy wersji i możliwość logowania losowymi danymi są faktami z advisory Fortinet i rekordu CVE. Opis potencjalnych działań po przejęciu oraz zalecenia dochodzeniowe są analizą Breachroad. Nie ma w tych źródłach potwierdzenia masowej eksploatacji.

Zespoły infrastruktury i SOC powinny ćwiczyć podobny scenariusz wspólnie, bo aktualizacja, ciągłość i dowody wzajemnie na siebie wpływają. Szkolenia cyberbezpieczeństwa dla organizacji pomagają przygotować decyzje przed incydentem. Niezależną ocenę segmentacji i zarządzania urządzeniami brzegowymi zapewnia audyt bezpieczeństwa IT.