Urządzenie, którego zadaniem jest detonowanie złośliwego kodu
Sandbox istnieje po to, żeby go atakowano. FortiSandbox kupuje się po to, by podejrzane pliki otwierały się w miejscu, które nie jest waszą siecią, były obserwowane, gdy zaczynają się źle zachowywać, i ocenione. Z założenia stoi dokładnie tam, gdzie przychodzi to, czemu się nie ufa. Właśnie dlatego nieuwierzytelnione wstrzyknięcie poleceń w jego interfejsie webowym to problem innej kategorii niż ten sam błąd na zwykłym serwerze.
CVE-2026-25089 jest dokładnie tym. Luka dotyczy interfejsu webowego FortiSandbox, FortiSandbox Cloud i FortiSandbox PaaS i pozwala nieuwierzytelnionemu napastnikowi wykonać nieuprawnione polecenia przez specjalnie spreparowane żądania HTTP. Ma ocenę CVSS 9.1. Fortinet ujawnił ją i załatał 9 czerwca 2026 roku.
W połowie czerwca zaczęły się ataki, w połowie lipca zauważył je katalog
Wykorzystywanie trzech luk FortiSandbox zaobserwowano w praktyce w weekend mniej więcej 14-16 czerwca, a niezależne śledzenie odnotowało wykorzystywanie CVE-2026-39808 już 12 czerwca. Prasa branżowa pisała o tym wtedy: Help Net Security 16 czerwca, Qualys dzień później, obok materiałów The Hacker News i SecurityWeek. Dwie z trzech, CVE-2026-39808 i CVE-2026-39813, Fortinet ujawnił już w kwietniu. Trzecia, CVE-2026-25089, została załatana 9 czerwca, kilka dni przed początkiem ataków.
16 lipca 2026 roku CISA opublikowała wersję katalogu 2026.07.16 i dodała trzy pozycje. Dwie z nich to luki FortiSandbox, CVE-2026-25089 i CVE-2026-39808. Trzecia to luka deserializacji w Microsoft SharePoint, CVE-2026-58644.
Policzcie dni. Potwierdzone, publicznie opisane wykorzystywanie w praktyce w połowie czerwca. Wpis do federalnego katalogu 16 lipca. Dzieli je jakieś trzydzieści dni, na urządzeniu osiągalnym z internetu, z nieuwierzytelnioną luką zdalnego wykonania kodu, a przez te trzydzieści dni informacja nie była tajna. Była w ostrzeżeniach producenta i w prasie branżowej.
Trzeciej nadal brakuje
W tej czerwcowej fali zgłoszono trzy CVE FortiSandbox jako wykorzystywane. Dwie skatalogowano 16 lipca. CVE-2026-39813, luka przejścia po ścieżce w API JRPC FortiSandbox, którą da się użyć do obejścia uwierzytelniania, w katalogu nie figuruje.
To jest ta część, która powinna zmienić sposób korzystania z katalogu, a nie tylko tempo. Wpis do KEV to mocny sygnał pozytywny: jeśli coś tam jest, jest wykorzystywane i trzeba działać. Brak wpisu to sygnał znacznie słabszy, niż zakłada większość programów łatania. CVE-2026-39813 zgłoszono jako wykorzystywaną obok tych dwóch, które trafiły na listę, w tej samej fali, w tej samej rodzinie produktów, i do katalogu nie weszła. Organizacja, która łata to, co CISA wymienia, i odkłada to, czego CISA nie wymienia, właśnie odłożyła lukę, której napastnicy używali w czerwcu.
Trzydniowy zegar na maszynie pod kontrolą zmian
Wszystkie trzy pozycje dodane 16 lipca mają termin usunięcia na 19 lipca 2026 roku. Trzy dni.
Dla operatora w Unii sam federalny termin nie jest wiążący i kusi, żeby odłożyć go jako amerykański szczegół administracyjny. Bardziej przydaje się jako odczyt powagi. Termin trzydniowy to sposób, w jaki katalog mówi, że nie oczekuje czekania na kolejne okno. Niewygodne jest zderzenie z rzeczywistością: urządzenie sandboxowe leży pod kontrolą zmian właśnie dlatego, że bada ruch produkcyjny, a trzy dni nie są w większości organizacji oknem zmian. To napięcie jest prawdziwym problemem operacyjnym i nie rozwiązuje się przez uważniejsze czytanie terminu.
Pod NIS2 ekspozycja nie leży w amerykańskim terminie, lecz w zwykłym obowiązku należytej staranności, a nieuwierzytelniona luka zdalnego wykonania kodu na urządzeniu bezpieczeństwa, wykorzystywana w praktyce przez miesiąc przy dostępnej łatce producenta, jest trudna do wytłumaczenia jako ryzyko zaakceptowane.
Przełóżcie wyzwalacz
Zalecenie jest małe i konkretne. Jeśli wasz proces podatnościowy rusza, gdy coś pojawi się w KEV, rusza jakiś miesiąc za późno i całe pozycje mu umykają. To nie jest krytyka katalogu, który robi to, co zapowiada: notuje to, o czym wiadomo, że jest wykorzystywane, gdy dowody osiągną próg. To krytyka używania kanału potwierdzeń jako systemu wczesnego ostrzegania.
Zróbcie trzy rzeczy. Zapiszcie się bezpośrednio na kanały ostrzeżeń PSIRT każdego producenta, którego urządzenia kończą niezaufany ruch, bo Fortinet opublikował to w czerwcu, a katalog odezwał się w lipcu. Dajcie urządzeniom bezpieczeństwa na styku z internetem własny tor łatania z krótszym zegarem niż reszta infrastruktury, bo są jednocześnie najbardziej wystawionymi i najmocniej objętymi kontrolą zmian zasobami, jakie macie. I sprawdźcie swój park FortiSandbox pod kątem wszystkich trzech czerwcowych CVE, nie dwóch skatalogowanych.
Czytaj dalej: 430 000 zapór stało się linią zasilania ransomware | Sfałszowany token otwiera każdy PC pod zarządem narzędzia



