Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W ekosystemie Java ujawniono krytyczną podatność typu remote code execution (RCE) w bibliotece Fastjson 1.x, szeroko wykorzystywanej do przetwarzania danych JSON. Luka dotyczy scenariuszy, w których aplikacja oparta na Spring Boot przyjmuje kontrolowane przez atakującego dane wejściowe i przekazuje je do podatnego parsera. W określonych warunkach może to doprowadzić do zdalnego wykonania kodu bez uwierzytelnienia, z uprawnieniami procesu Java.
W skrócie
Podatność otrzymała oznaczenie CVE-2026-16723 oraz ocenę CVSS 9.0. Zagrożone są wersje Fastjson od 1.2.68 do 1.2.83, szczególnie w aplikacjach uruchamianych jako wykonywalne fat-JAR-y Spring Boot. Co istotne, eksploatacja nie wymaga aktywnego AutoType ani klasycznego gadget chain w classpath, co znacząco obniża próg wejścia dla atakujących.
- Podatne wersje: Fastjson 1.2.68–1.2.83
- Typ zagrożenia: zdalne wykonanie kodu bez uwierzytelnienia
- Najbardziej narażone środowiska: Spring Boot executable fat-JAR
- Status: doniesienia o aktywnej eksploatacji, brak finalnej poprawki dla linii 1.x
- Zalecane obejścia: SafeMode lub migracja do Fastjson2
Kontekst / historia
Fastjson od lat należy do najczęściej rozpoznawanych bibliotek JSON w środowisku Java, ale wcześniej wielokrotnie pojawiał się w analizach bezpieczeństwa dotyczących deserializacji oraz rozpoznawania typów. Najnowszy problem wpisuje się w ten kontekst, jednak wyróżnia się tym, że dotyczy również końcowej, wcześniej rekomendowanej gałęzi 1.x.
Oznacza to, że organizacje, które historycznie zaktualizowały bibliotekę do wersji 1.2.83, nie są automatycznie zabezpieczone przed nowym wektorem ataku. Dodatkowo znaczenie incydentu zwiększają informacje o próbach wykorzystania luki w środowiskach produkcyjnych, co przenosi zagrożenie z poziomu teoretycznego do realnego ryzyka operacyjnego.
Analiza techniczna
Mechanizm ataku opiera się na sposobie rozwiązywania typów przez Fastjson. Napastnik może posłużyć się kontrolowaną wartością pola @type, która zostaje przekształcona w odwołanie do zasobu klasy. W zgodnym środowisku Spring Boot executable fat-JAR taka ścieżka może zostać spreparowana tak, aby doprowadzić do załadowania kontrolowanego kodu bajtowego.
Kluczową rolę odgrywa tu zachowanie loadera Spring Boot dla fat-JAR-ów. To właśnie specyfika tego modelu pakowania i uruchamiania aplikacji umożliwia wykorzystanie zagnieżdżonych ścieżek JAR w sposób, który następnie może zostać użyty przez mechanizmy Fastjson. Jeżeli załadowany zasób zawiera odpowiednią adnotację @JSONType, może zostać uznany za zaufany i przejść dalszą walidację typów.
Ta ścieżka eksploatacji jest szczególnie niebezpieczna, ponieważ nie wymaga klasycznego łańcucha gadgetów obecnego już w classpath. Również wyłączenie AutoType nie eliminuje ryzyka w opisanym scenariuszu. Z perspektywy obrońców oznacza to, że wcześniejsze założenia dotyczące bezpiecznej konfiguracji Fastjson mogą być niewystarczające.
Według dostępnych analiz podatne ścieżki wejściowe obejmują między innymi JSON.parse, JSON.parseObject(String) oraz JSON.parseObject(String, Class). Nawet wiązanie danych do z góry określonej klasy nie musi gwarantować bezpieczeństwa, jeśli obiekt docelowy zawiera pola typu Object lub Map, w których można osadzić złośliwy ładunek.
Istotne jest także to, że podatność nie obejmuje wszystkich modeli wdrożenia. Jako niepodatne wskazywano zwykłe, niezagnieżdżone JAR-y, część ogólnych uber-JAR-ów oraz wdrożenia WAR na serwerach takich jak Tomcat czy Jetty. Ryzyko zależy więc nie tylko od wersji biblioteki, lecz także od sposobu pakowania i uruchamiania aplikacji.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją podatności jest możliwość nieautoryzowanego wykonania kodu na serwerze aplikacyjnym. W praktyce może to prowadzić do przejęcia procesu Java, uruchamiania poleceń systemowych, pobierania kolejnych komponentów malware, modyfikacji danych albo ustanowienia trwałego dostępu do środowiska.
Ryzyko jest szczególnie wysokie tam, gdzie Fastjson przetwarza dane przychodzące bezpośrednio z sieci, zwłaszcza w publicznie dostępnych interfejsach API. Ponieważ atak nie wymaga uwierzytelnienia, eksploatacja może rozpocząć się od pojedynczego żądania HTTP zawierającego odpowiednio przygotowany dokument JSON.
- możliwość przejęcia kontroli nad aplikacją i systemem operacyjnym
- wysokie ryzyko wdrożenia malware lub loaderów
- potencjalny wyciek, modyfikacja lub zniszczenie danych
- zwiększona trudność detekcji ze względu na zależność od modelu wdrożenia
- potwierdzone zainteresowanie atakujących środowiskami produkcyjnymi
Rekomendacje
Priorytetem powinno być szybkie ustalenie, gdzie w organizacji wykorzystywany jest Fastjson 1.x, zarówno bezpośrednio, jak i pośrednio przez zależności dostarczane przez producentów zewnętrznych. Sama obecność biblioteki nie daje pełnego obrazu ryzyka, dlatego konieczna jest również weryfikacja modelu wdrożenia oraz sposobu przetwarzania danych wejściowych.
- włączyć SafeMode za pomocą parametru
-Dfastjson.parser.safeMode=true - rozważyć zastosowanie wariantu
com.alibaba:fastjson:1.2.83_noneautotype, jeśli natychmiastowa migracja nie jest możliwa - ograniczyć przekazywanie nieufnych danych wejściowych do metod parsujących Fastjson
- przeanalizować kod pod kątem użycia
JSON.parseiJSON.parseObject - sprawdzić, czy aplikacje są dystrybuowane jako Spring Boot executable fat-JAR
- zaplanować migrację do Fastjson2 jako docelowe rozwiązanie
Zespoły SOC i IR powinny równolegle uruchomić aktywne polowanie na ślady kompromitacji. Warto monitorować nietypowe wartości @type w ruchu HTTP i logach aplikacyjnych, odwołania do zagnieżdżonych ścieżek JAR, nieoczekiwane połączenia wychodzące z serwerów aplikacyjnych, uruchamianie nowych procesów potomnych przez JVM oraz zmiany w katalogach tymczasowych i innych wrażliwych lokalizacjach systemu plików.
Podsumowanie
CVE-2026-16723 to jedna z najpoważniejszych ostatnio ujawnionych luk w ekosystemie Java, ponieważ łączy krytyczny wpływ z niskim progiem eksploatacji i zależnością od powszechnie spotykanego modelu wdrożeniowego. Szczególnie niepokojący jest fakt, że atak może być skuteczny bez aktywnego AutoType i bez klasycznego gadget chain.
Organizacje korzystające z Fastjson 1.x w aplikacjach Spring Boot powinny potraktować ten problem priorytetowo. W obecnej sytuacji najważniejsze są szybka inwentaryzacja, wdrożenie dostępnych obejść, wzmożone monitorowanie środowiska oraz przygotowanie migracji do bezpieczniejszej gałęzi biblioteki.