Fortinet CVE-2025-61624 w KEV: średni wynik, aktywne wykorzystanie

Wynik CVSS pomaga porównywać techniczne właściwości podatności, ale nie odpowiada na wszystkie pytania o ryzyko firmy. CVE-2025-61624 ma wynik 5,4, czyli „średni”, a mimo to 16 października trafiła do katalogu aktywnie wykorzystywanych podatności CISA KEV. Dla amerykańskich agencji federalnych termin działań przypada 19 października.

Podatność dotyczy wielu produktów Fortinet: FortiOS, FortiProxy, FortiSwitchManager i FortiPAM. Według rekordu CVE uwierzytelniony napastnik z profilem administratora i co najmniej uprawnieniami odczytu oraz zapisu może, za pomocą określonych poleceń CLI, zapisywać albo usuwać dowolne pliki. To błąd ograniczenia ścieżki pliku, sklasyfikowany jako CWE-22.

Wniosek Breachroad: średni wynik nie oznacza niskiego priorytetu, kiedy urządzenie jest ważnym punktem kontroli, a podatność jest wykorzystywana w rzeczywistych atakach. Jednocześnie nie jest to opis zdalnego ataku bez uwierzytelnienia. Dochodzenie powinno koncentrować się także na tym, skąd napastnik mógł uzyskać uprzywilejowany dostęp.

Dlaczego CVSS i KEV mówią o czymś innym

Wektor CVSS dla tej luki zakłada dostęp lokalny i wysokie uprawnienia. To obniża ocenę w porównaniu z błędem dostępnym z internetu bez konta. Jeśli jednak przestępca wcześniej ukradł dane administratora, przejął stację zarządzającą albo wykorzystał inną lukę, możliwość zapisu i usuwania plików może być kolejnym etapem łańcucha.

CVSS opisuje właściwości pojedynczej podatności. KEV mówi, że istnieją dowody rzeczywistego wykorzystania. Priorytet organizacji powinien łączyć oba sygnały z rolą urządzenia, jego ekspozycją, dostępem do danych oraz możliwością wykrycia nadużycia.

Nie należy wyciągać odwrotnego wniosku: wpis w KEV nie dowodzi, że każda instalacja została przejęta. Potwierdza potrzebę pilnej weryfikacji, aktualizacji i sprawdzenia śladów.

Produkty i gałęzie wymienione w rekordzie

Oficjalny rekord CVE wskazuje między innymi następujące zakresy:

• FortiOS 7.6.0–7.6.4 oraz 7.4.0–7.4.9, a także wymienione wydania gałęzi 7.2, 7.0 i 6.4;
• FortiProxy 7.6.0–7.6.4 i 7.4.0–7.4.11 oraz wydania gałęzi 7.2 i 7.0;
• FortiSwitchManager 7.2.0–7.2.7 i 7.0.0–7.0.6;
• FortiPAM obejmujący wskazane wydania od 1.0 do 1.7.

To szeroki zakres, dlatego nie warto ręcznie zgadywać docelowej wersji tylko na podstawie końca przedziału. Należy sprawdzić konkretny produkt i gałąź w biuletynie Fortinet FG-IR-26-122, uwzględnić zależności klastra oraz wykonać wspieraną ścieżkę aktualizacji.

Plan działania dla firmy

1. Zbuduj rzeczywisty inwentarz. Oprócz urządzeń brzegowych sprawdź menedżery przełączników, proxy i systemy uprzywilejowanego dostępu.
2. Potwierdź wersję na każdym węźle. Nie opieraj się wyłącznie na numerze zapisanym w CMDB lub umowie serwisowej.
3. Sprawdź instrukcję PSIRT dla danej gałęzi. Zaplanuj kopię konfiguracji, okno serwisowe, zgodność klastra i możliwość bezpiecznego wycofania.
4. Przejrzyj konta administracyjne. Zweryfikuj nieużywane konta, zakres profili, źródła logowania, MFA oraz dostęp dostawców.
5. Zachowaj i przeanalizuj logi CLI. Szukaj nietypowych poleceń, sesji administracyjnych, zmian plików i działań spoza zatwierdzonego okna.
6. Porównaj konfigurację z zaufaną kopią. Sama dostępność urządzenia nie dowodzi jego integralności.
7. Sprawdź systemy prowadzące do panelu. Przejęta stacja administratora, VPN albo konto SSO może wyjaśniać wymagany dostęp.
8. Zmień sekrety na podstawie ryzyka. Jeżeli są dowody nadużycia, rotacja musi objąć dane, które mogły być dostępne z urządzenia, nie tylko hasło jednego operatora.

Aktualizacja jest konieczna, lecz przy aktywnym wykorzystaniu zadanie nie powinno kończyć się wyłącznie raportem zgodności wersji.

Pytania dla właściciela usługi

Właściciel biznesowy nie musi analizować poleceń CLI, ale powinien dostać jasne odpowiedzi:

• czy korzystamy z jednego z wymienionych produktów i w jakiej roli;
• czy urządzenie jest aktualne według właściwego biuletynu producenta;
• kto miał dostęp administracyjny i czy logi pozwalają to potwierdzić;
• jakie usługi ucierpią podczas aktualizacji lub izolacji;
• czy znaleziono sygnały kompromitacji i jaki jest zakres dalszej analizy;
• kto formalnie akceptuje ryzyko, jeśli aktualizacja jest odroczona.

Taki zestaw zapobiega dwóm błędom: bagatelizowaniu luki przez wynik 5,4 oraz ogłaszaniu incydentu bez dowodów tylko dlatego, że CVE znalazło się w KEV.

Fakty i wnioski

Opis błędu, wymagane uprawnienia, zakres produktów i wynik CVSS pochodzą z rekordu CVE oraz biuletynu Fortinet. Aktywne wykorzystanie i termin dla amerykańskich agencji wynikają z katalogu CISA. Termin nie jest uniwersalnym obowiązkiem prawnym dla przedsiębiorstw w Polsce.

Sposób połączenia CVSS, KEV, roli urządzenia i dowodów kompromitacji jest rekomendacją Breachroad. Pomaga go utrwalić proces zarządzania podatnościami połączony z planem reagowania na incydenty. Zespoły infrastruktury, SOC i właściciele usług mogą przećwiczyć podobny scenariusz podczas szkoleń cyberbezpieczeństwa dla organizacji, a konfigurację, segmentację i dostęp uprzywilejowany ocenić w ramach audytu bezpieczeństwa IT.