FortiSandbox: aktywnie wykorzystywane luki CVE-2026-39808 i 25089

Jest szczególny rodzaj ironii w tym, że urządzenie kupione po to, żeby wykrywać złośliwe oprogramowanie, samo staje się drogą wejścia do sieci. Dokładnie to dzieje się z FortiSandbox — rozwiązaniem Fortinetu do analizy podejrzanych plików w izolowanym środowisku. Dwie podatności, CVE-2026-39808 i CVE-2026-25089, obie ocenione na CVSS 9.1, pozwalają nieuwierzytelnionemu napastnikowi wykonać polecenia systemu operacyjnego na urządzeniu. Amerykańska agencja CISA potwierdziła ich aktywne wykorzystywanie i dopisała obie do katalogu KEV (Known Exploited Vulnerabilities), wyznaczając agencjom federalnym termin naprawy na 19 lipca 2026.

Poprawki istnieją od dawna — Fortinet usunął CVE-2026-39808 w kwietniu, a CVE-2026-25089 w czerwcu 2026. To znaczy, że problemem nie jest brak łatki, tylko czas, przez jaki niezałatane urządzenia stoją wystawione do sieci. Poniżej rozkładamy to na części: co dokładnie jest podatne, dlaczego akurat sandbox jest tak wartościowym celem, jak wygląda mechanika ataku, po czym poznać kompromitację i co zrobić w kolejności, która ma sens.

Czym właściwie jest FortiSandbox i co ma w środku

Zanim ocenimy ryzyko, warto zrozumieć funkcję urządzenia, bo od niej zależy skala skutków.

FortiSandbox to system klasy sandbox / detonation chamber. Jego zadanie polega na przyjmowaniu plików i adresów URL, których inne komponenty bezpieczeństwa nie potrafią jednoznacznie zaklasyfikować, uruchamianiu ich w kontrolowanym, odizolowanym środowisku (najczęściej w maszynach wirtualnych z różnymi wersjami systemów i aplikacji) i obserwowaniu, co próbują zrobić. Jeśli plik szyfruje dokumenty, modyfikuje klucze rejestru, wstrzykuje kod do innych procesów albo łączy się z serwerem sterującym — sandbox to widzi i wydaje werdykt.

Z tej funkcji wynikają cztery cechy, które czynią z niego wyjątkowo atrakcyjny cel:

Po pierwsze, sandbox stoi w uprzywilejowanym miejscu sieci. Żeby przyjmować próbki, musi być osiągalny dla bramy pocztowej, firewalla, proxy webowego i stacji końcowych. To oznacza szeroką łączność wewnętrzną — dokładnie odwrotność izolacji, jakiej wymagalibyśmy od systemu przetwarzającego złośliwe pliki.

Po drugie, ma poświadczenia do innych systemów. Integracja z FortiGate, FortiMail, FortiWeb czy FortiClient wymaga kluczy API i kont serwisowych. Kto przejmie sandbox, dostaje w prezencie zestaw poświadczeń do infrastruktury bezpieczeństwa.

Po trzecie, przechodzi przez niego treść firmowa. Załączniki z poczty, pliki pobierane przez pracowników, dokumenty przesyłane przez formularze. W praktyce sandbox widzi znaczącą część tego, co wchodzi do organizacji — łącznie z dokumentami wrażliwymi, które trafiły do analizy „na wszelki wypadek”.

Po czwarte, jest zaufany i słabo monitorowany. Ruch wychodzący z sandboxa do internetu jest normą (musi pobierać aktualizacje sygnatur, a często pozwala się badanym próbkom „zadzwonić do domu”, by zaobserwować zachowanie). Alarm o nietypowym połączeniu z tego urządzenia zwyczajnie nie zadziała — bo nietypowe połączenia są tam codziennością.

Zestawmy to razem: urządzenie z szerokim dostępem wewnętrznym, kluczami do innych systemów bezpieczeństwa, wglądem w treść firmową i naturalnie „szumnym” ruchem sieciowym. Trudno wymarzyć sobie lepszy przyczółek.

Mechanika: wstrzyknięcie poleceń systemu operacyjnego

Obie luki należą do klasy OS command injection, katalogowanej jako CWE-78. Mechanizm jest prosty do zrozumienia i, niestety, równie prosty do popełnienia w kodzie.

Aplikacja webowa urządzenia przyjmuje dane od użytkownika (parametr w żądaniu HTTP), a następnie — zamiast użyć bezpiecznego wywołania systemowego z rozdzieleniem argumentów — skleja z nich ciąg znaków i przekazuje go do interpretera powłoki. Interpreter nie odróżnia „danych” od „poleceń”: widzi tylko tekst do wykonania. Jeśli w danych znajdą się znaki o znaczeniu specjalnym dla powłoki — średnik, potok, &&, odwrotny apostrof, $(...) — kończą one zamierzone polecenie i zaczynają nowe, napisane przez napastnika.

Uproszczony przykład tego wzorca (celowo bez szczegółów pasujących do konkretnego produktu):

# Kod podatny — parametr trafia wprost do powłoki
cmd = "ping -c 1 " + user_input
system(cmd)

# user_input = "8.8.8.8; id"
# powłoka wykonuje: ping -c 1 8.8.8.8 ; id

W przypadku FortiSandboxa istotne są dwa wzmacniacze ryzyka. Po pierwsze, ataki przeprowadza się specjalnie spreparowanymi żądaniami HTTP — czyli tym samym kanałem, którym urządzenie normalnie się komunikuje. Po drugie — i to jest sedno — luki są nieuwierzytelnione (unauthenticated). Napastnik nie potrzebuje konta, hasła ani ważnej sesji. Wystarczy, że osiągnie interfejs urządzenia po sieci.

Wykonanie polecenia następuje w kontekście procesu obsługującego aplikację webową. Nawet jeśli nie jest to od razu root, napastnik uzyskuje punkt wykonania kodu wewnątrz urządzenia bezpieczeństwa, skąd może rozpoznawać sieć, sięgać po pliki konfiguracyjne, wykradać klucze integracji i budować trwałą obecność.

Dlaczego CVSS 9.1, a nie 10.0

Ocena 9.1 zamiast maksymalnej wynika zwykle z tego, że wektor nie daje pełnego kompletu skutków w modelu CVSS (np. wpływ na dostępność jest oceniony niżej niż na poufność i integralność). Dla obrońcy ta różnica nie ma znaczenia praktycznego. Liczy się kombinacja: zdalnie, bez uwierzytelnienia, wykonanie poleceń, potwierdzona eksploatacja w realnych atakach. To zestaw, który stawia podatność na szczycie kolejki niezależnie od drugiej cyfry po przecinku — o czym piszemy szerzej w tekście o priorytetyzacji krytycznych podatności.

Co dokładnie jest podatne i gdzie są poprawki

Element	Stan
Produkty	FortiSandbox, FortiSandbox Cloud, FortiSandbox PaaS
Klasa błędu	OS command injection (CWE-78)
Uwierzytelnienie	niewymagane
Ocena	CVSS 9.1 (obie luki)
CVE-2026-39808	poprawka wydana w kwietniu 2026
CVE-2026-25089	poprawka wydana w czerwcu 2026
Status	aktywna eksploatacja, obie w katalogu CISA KEV
Termin dla agencji USA	19 lipca 2026

Warto odnotować, że w publikacjach badawczych z tego okresu pojawia się także CVE-2026-39813 analizowane razem z powyższymi. Przy planowaniu prac nie traktuj więc sprawy jako „dwóch pojedynczych CVE”, tylko sprawdź komplet biuletynów Fortinetu dla swojej wersji i doprowadź urządzenie do bieżącego wydania, zamiast łatać punktowo.

Uwaga dotycząca wariantów chmurowych: obecność FortiSandbox Cloud i PaaS na liście nie zwalnia z działania. Ustal u dostawcy, kto odpowiada za aktualizację instancji i poproś o pisemne potwierdzenie wersji oraz daty wgrania poprawki. To standardowy element zarządzania ryzykiem dostawców, o którym łatwo zapomnieć przy usługach zarządzanych.

Urządzenia brzegowe bezpieczeństwa — powtarzalny wzorzec 2026 roku

Ta historia nie jest odosobniona i właśnie dlatego jest ważna. W ciągu ostatnich miesięcy ten sam schemat powtórzył się wielokrotnie: krytyczna, nieuwierzytelniona luka w urządzeniu bezpieczeństwa lub dostępowym, szybko trafiająca do realnych ataków. Pisaliśmy o SonicWall SMA1000, o FortiClient EMS i o FortiCloud SSO.

Dlaczego akurat ta kategoria? Bo łączy cztery cechy, których napastnik szuka:

Jest wystawiona do sieci — z definicji, bo obsługuje ruch przychodzący albo zdalny dostęp.
Nie da się na niej zainstalować EDR-a. To zamknięty system; klasyczne narzędzia detekcji na hoście nie mają tam wstępu, więc napastnik działa w martwym polu.
Ma wysokie uprawnienia i zaufanie. Terminuje VPN, widzi ruch, trzyma poświadczenia, integruje się z resztą infrastruktury.
Rzadko jest w cyklu łatania. Serwery aktualizuje się co miesiąc; „apliance’y” bywają traktowane jak sprzęt sieciowy — „działa, nie ruszaj” — i stoją latami na wersji z wdrożenia.

Wniosek strategiczny jest niewygodny: urządzenia bezpieczeństwa muszą być łatane szybciej niż serwery, a nie wolniej. W praktyce zwykle jest odwrotnie.

Jak sprawdzić, czy nie jest już za późno

Przy podatności potwierdzonej w aktywnych atakach samo wgranie poprawki nie odpowiada na pytanie, czy ktoś nie wszedł wcześniej. Ponieważ na urządzeniu nie postawisz agenta EDR, detekcja opiera się na tym, co widać z zewnątrz i w logach.

Logi dostępu do interfejsu webowego. Szukaj żądań do endpointów administracyjnych z adresów spoza puli administracyjnej, serii nietypowych żądań w krótkim czasie oraz parametrów zawierających znaki powłoki (;, |, &&, `, $(). Ich obecność w polach, które powinny przyjmować nazwę pliku albo adres IP, jest sygnałem jednoznacznym.

Ruch wychodzący z urządzenia. To najcenniejsze źródło, mimo wspomnianego szumu. Zbuduj listę tego, co jest normalne (serwery aktualizacji producenta, usługi reputacyjne) i wychwytuj resztę: połączenia do świeżo zarejestrowanych domen, długo utrzymywane sesje, regularne „pulsy” w równych odstępach (charakterystyczne dla kanału C2), transfery o nietypowym wolumenie.

Ruch od urządzenia w głąb sieci. Sandbox powinien rozmawiać z konkretnym zestawem systemów. Próby logowania do kontrolera domeny, skanowanie zakresów adresowych czy połączenia SMB do stacji roboczych to zachowanie, którego w tym profilu nie ma prawa być — i doskonała reguła detekcyjna, którą warto mieć niezależnie od tej konkretnej luki. Szerzej o budowaniu takich reguł piszemy przy monitoringu bezpieczeństwa.

Integralność konfiguracji i kont. Porównaj bieżącą konfigurację z ostatnią znaną-dobrą kopią. Zwróć uwagę na nowe konta administracyjne, dodane klucze SSH, zmienione ustawienia zdalnego dostępu i nowe zadania cykliczne.

Wsparcie producenta. Jeśli podejrzewasz kompromitację, zabezpiecz zrzut stanu urządzenia i skontaktuj się z Fortinetem, zanim zaczniesz „sprzątać”. Ograniczony dostęp do systemu operacyjnego sprawia, że część analizy powłamaniowej jest wykonalna wyłącznie po stronie producenta — a przedwczesne przywrócenie fabryczne skasuje dowody.

Plan naprawczy w kolejności, która ma sens

Krok 1: Ustal, co masz i gdzie jest widoczne. Zinwentaryzuj wszystkie instancje FortiSandbox — fizyczne, wirtualne, chmurowe i te w zapomnianych lokalizacjach. Następnie sprawdź, co z nich jest osiągalne z internetu. Do tego służy zarządzanie zewnętrzną powierzchnią ataku (EASM); jeśli nie masz narzędzia, zacznij od prostego skanu własnych zakresów adresowych.

Krok 2: Odetnij interfejs zarządzania od świata. To działanie, które daje największy efekt w najkrótszym czasie. Panel administracyjny urządzenia bezpieczeństwa nie ma żadnego powodu być dostępny publicznie. Ogranicz dostęp do wydzielonej sieci administracyjnej lub VPN-a, najlepiej z listą dozwolonych adresów.

Krok 3: Zaktualizuj do wersji z kompletem poprawek. Nie tylko do tej usuwającej jedno CVE — do bieżącego wydania wspieranej gałęzi. Sprawdź w biuletynach producenta, czy Twoja wersja nie jest podatna także na inne błędy z tej serii.

Krok 4: Zrotuj sekrety. Jeśli urządzenie było wystawione i niezałatane w oknie ekspozycji, załóż, że jego sekrety mogły wyciec: klucze API integracji, hasła kont serwisowych, certyfikaty, poświadczenia do systemów, z którymi się łączy. Sama łatka nie unieważnia wykradzionych kluczy — to zasada, którą powtarzamy przy każdym poważnym incydencie.

Krok 5: Ogranicz zaufanie sieciowe urządzenia. Zadaj pytanie projektowe: dlaczego sandbox może inicjować połączenia do dowolnego hosta w sieci wewnętrznej? Zdefiniuj listę dozwolonych kierunków i zablokuj resztę. Ten sam mechanizm, który ogranicza skutki kompromitacji sandboxa, ogranicza też skutki kompromitacji dowolnego innego systemu — to praktyczne zastosowanie segmentacji sieci wewnętrznej.

Krok 6: Wpisz „apliance’y” do procesu. Doprowadź do stanu, w którym urządzenia bezpieczeństwa mają wyznaczonego właściciela, subskrypcję biuletynów producenta i zdefiniowany czas reakcji na krytyczne CVE — mierzony w dniach, nie w kwartałach. To element dojrzałego procesu zarządzania podatnościami.

Najczęstsze pytania (FAQ)

Nasz FortiSandbox nie jest wystawiony do internetu. Czy możemy odpuścić? Nie odpuszczaj, ale możesz świadomie ustawić priorytet niżej. Brak ekspozycji publicznej istotnie zmniejsza ryzyko, natomiast luka pozostaje wykorzystywalna przez kogoś, kto ma już dostęp do sieci wewnętrznej — czyli w scenariuszu po phishingu lub przejęciu stacji. Ponieważ sandbox jest z założenia osiągalny dla wielu systemów wewnętrznych, jest to wygodny cel drugiego kroku.

Fortinet wydał poprawki w kwietniu i czerwcu. Skąd aktywna eksploatacja w lipcu? To typowe zjawisko „n-day”. Napastnicy analizują opublikowane poprawki, odtwarzają z nich szczegóły błędu i skanują internet w poszukiwaniu niezaktualizowanych urządzeń. Okno między wydaniem łatki a jej wgrożeniem jest w praktyce oknem ataku — i przy urządzeniach brzegowych bywa liczone w miesiącach.

Czy WAF przed urządzeniem wystarczy? Traktuj to jako środek tymczasowy. Reguła blokująca znane wzorce wstrzyknięć podniesie poprzeczkę, ale ładunki da się modyfikować, a wirtualna łatka nie usuwa przyczyny. Użyj jej, żeby kupić czas na okno serwisowe — nie zamiast aktualizacji.

Zaktualizowaliśmy urządzenie. Czy trzeba jeszcze coś robić? Tak, dwie rzeczy. Po pierwsze, przejrzyj logi i ruch wstecz za okres, w którym urządzenie było podatne i wystawione. Po drugie, jeśli znajdziesz cokolwiek nietypowego — zrotuj poświadczenia integracji i potraktuj sprawę jako incydent zgodnie z planem reagowania.

Jak w ogóle sprawdzić, ile mamy takich urządzeń i czy są aktualne? Od inwentaryzacji: lista urządzeń, wersje oprogramowania, właściciele, ekspozycja sieciowa. W praktyce najwięcej znalezisk daje porównanie tego, co „powinno być”, z tym, co faktycznie odpowiada na skanie. Odezwij się, jeśli chcesz, żebyśmy przeprowadzili takie rozpoznanie zewnętrzne u Ciebie.

Podsumowanie

CVE-2026-39808 i CVE-2026-25089 to przypadek, w którym wszystko, co potrzebne do obrony, było dostępne od miesięcy — poprawki wyszły w kwietniu i czerwcu — a mimo to urządzenia padają ofiarą ataków w lipcu. Problem nie leży w wiedzy ani w technologii, tylko w procesie: urządzenia bezpieczeństwa wypadają z cyklu łatania, bo „działają”, a ich kompromitacja jest wyjątkowo trudna do zauważenia, bo nie da się na nich uruchomić klasycznej detekcji.

Praktyczna lista jest krótka: zinwentaryzuj instancje, zdejmij panele zarządzania z internetu, doprowadź oprogramowanie do bieżącej wersji, zrotuj sekrety, jeśli byłeś w oknie ekspozycji, i ogranicz to, z czym urządzenie może rozmawiać w sieci. Jeśli chcesz sprawdzić, ile takich systemów widać z zewnątrz w Twojej organizacji i jak szybko domykasz krytyczne okna — zweryfikujmy to kontrolowanym testem.

Źródła i dalsza lektura: Fortinet PSIRT Advisories, CISA KEV, The Register, Help Net Security, CWE-78.