CISA wpisuje lukę CVE-2025-61624 w CLI Fortinet na listę wykorzystywanych podatności, gdy Unit 42 wiąże ją z implantem PEERSTITCH

Amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA) 16 października dodała CVE-2025-61624, lukę typu path traversal (przejście przez katalogi) w kilku produktach Fortinet, do swojego katalogu znanych wykorzystywanych podatności (Known Exploited Vulnerabilities, KEV), powołując się na dowody aktywnego wykorzystywania. Ta sama aktualizacja objęła także CVE-2026-102764, obejście uwierzytelniania w BeyondTrust Remote Support. CISA zachęca wszystkie organizacje do priorytetowego usuwania luk wymienionych w katalogu.

Biuletyn FG-IR-26-122 firmy Fortinet, opublikowany po raz pierwszy 2026-04-14, opisuje słabość typu path traversal (CWE-22) w interfejsie wiersza poleceń (CLI) wspólnym dla FortiOS, FortiProxy, FortiPAM i FortiSwitchManager. Według firmy Fortinet atakujący, który już posiada uprzywilejowany dostęp, mógłby przekazać spreparowane argumenty do istniejących poleceń, aby zapisywać lub usuwać dowolne pliki. Producent ocenia problem jako Medium z wynikiem CVSSv3 6.0, klasyfikuje go jako wymagający uwierzytelnienia ze skutkiem w postaci eskalacji uprawnień i oznacza jako znany z wykorzystywania. FortiOS jest naprawiony w wersjach 7.6.5 i 7.4.10 lub nowszych, natomiast żadne wydanie z gałęzi 7.2, 7.0 i 6.4 nie ma poprawki i musi zostać przeniesione do naprawionego wydania. Fortinet wymienia FortiProxy 7.6.5 i 7.4.12, FortiPAM 1.7.1 oraz FortiSwitchManager 7.2.8 i 7.0.7 jako wersje naprawione, przy czym starsze gałęzie FortiProxy i FortiPAM również wymagają migracji. Jak podaje biuletyn, wirtualna poprawka (virtual patch) jest dostępna w bazie FMWP firmy Fortinet.

Zespół Palo Alto Networks Unit 42 powiązał lukę z włamaniem u dostawcy usług zarządzanych (MSP) z branży telekomunikacyjnej, które datuje na wrzesień 2024 r. i śledzi jako CL-STA-0954, znane też jako UNC5820. Według Unit 42 atakujący najpierw wykorzystali CVE-2024-47575 na centralnym urządzeniu FortiManager i zabrali archiwum z bieżącymi konfiguracjami, materiałem kryptograficznym i bazami danych obejmującymi ponad 500 zarządzanych zapór FortiGate, które chroniły zarówno dostawcę, jak i jego klientów. Badacze stwierdzili, że atakujący później odzyskali z tych plików dane uwierzytelniające, otwierali sesje SSL VPN i nadużyli CVE-2025-61624 poprzez funkcję auto-script w FortiOS, aby przejść z dostępu administratora do uprawnień root. Dostęp ten posłużył do zainstalowania PEERSTITCH, który Unit 42 opisuje jako nowy rezydujący w pamięci implant ARM64, niezapisujący na dysku żadnego trwałego pliku binarnego, nieotwierający portów nasłuchujących i nienawiązujący połączeń wychodzących, lecz podczepiający się pod ruch legalnych procesów.

Unit 42 zgłosił także kanał reverse shell zbudowany przez nadużycie modułu Apache mod_md na zaporach oraz działania antyforensyczne, takie jak zatrzymywanie demonów logowania, czyszczenie logów awarii (crash logs) i usuwanie fałszywych kont oraz obiektów auto-script wkrótce po użyciu. Stwierdził, że część działań atakujących po uzyskaniu dostępu przypomina włamania, które powiązano z podejrzewanymi aktorami państwowymi, i ocenił ze średnią pewnością, że atakujący podszywali się pod FortiManager, aby pobierać konfiguracje z innych zapór. Unit 42 podkreślił, że jego dochodzenie objęło wyłącznie własne środowisko dostawcy: nie zbadał sieci klientów, a to, co dokumentuje, to ujawnienie konfiguracji zapór i danych uwierzytelniających klientów, a nie potwierdzone włamanie do samych sieci klientów.

Dla obrońców natychmiastowym krokiem jest aktualizacja dotkniętych produktów Fortinet lub migracja gałęzi, które nie mają poprawki. Unit 42 zaleca przegląd rewizji konfiguracji FortiOS pod kątem obiektów auto-script, których nazwy zawierają ciągi przejścia przez katalogi, sprawdzenie logów awarii pod kątem błędów segmentacji w demonach logowania, IKE i syslog, poszukiwanie nietypowych wykonywalnych obszarów pamięci w demonach logowania i VPN oraz audyt międzyprocesowych zapisów do pamięci między nimi. Badacze radzili też traktować dane uwierzytelniające i certyfikaty przechowywane przez platformę zarządzania jako skompromitowane, gdy tylko skompromitowana zostanie sama platforma, ponieważ ten materiał zaufania pozostaje ważny do czasu rotacji. „Ta kompromitacja nie kończy się także wraz z załataniem platformy” — napisał Unit 42.