Fastjson CVE-2026-16723: RCE aktywnie wykorzystywane

Krytyczna podatność CVE-2026-16723 w bibliotece Alibaba Fastjson 1.x jest wykorzystywana w realnych atakach. Najważniejsza wiadomość dla zespołów Java nie brzmi jednak tylko „kolejne RCE w parserze JSON”. Luka może działać przy wyłączonym AutoType, czyli w konfiguracji, którą wiele organizacji uznawało za podstawową ochronę przed historycznymi problemami Fastjson.

Według oficjalnego biuletynu Alibaba podatne są wersje 1.2.68–1.2.83, gdy aplikacja używa wykonywalnego pakietu Spring Boot typu fat JAR, a jednocześnie AutoType i SafeMode pozostają wyłączone. Fastjson 2 nie jest objęty tym problemem. Ponieważ ThreatBook obserwuje próby wykorzystania luki, administratorzy powinni potraktować działania ograniczające ryzyko i analizę śladów kompromitacji jako zadanie pilne.

Co dokładnie jest podatne

Warunki opisane przez producenta są węższe niż hasło „wszystkie Fastjson 1.x”, ale występują w bardzo popularnym modelu wdrożenia aplikacji Java. Zagrożona konfiguracja łączy:

• Fastjson od 1.2.68 do 1.2.83;
• Spring Boot uruchamiany jako wykonywalny fat JAR;
• wyłączony AutoType;
• wyłączony SafeMode, co jest ustawieniem domyślnym;
• przetwarzanie danych JSON, które napastnik może kontrolować.

Alibaba zweryfikowała podatność na JDK 8, 11, 17 i 21 oraz w aplikacjach opartych na Spring Boot 2, 3 i 4. Problem może być osiągalny przez popularne metody JSON.parse, JSON.parseObject(String) oraz JSON.parseObject(String, Class).

To ostatnie ma praktyczne znaczenie. Deserializacja do jawnie wskazanej klasy DTO nie jest wystarczającą ochroną, jeśli obiekt zawiera pola ogólnego typu, takie jak Object, Map albo zagnieżdżone struktury interpretowane dynamicznie. Granicą zaufania jest cały graf danych, nie tylko typ obiektu na najwyższym poziomie.

Dlaczego wyłączone AutoType nie wystarcza

Historycznie wiele ataków na Fastjson wykorzystywało AutoType do wskazania klasy, którą parser miał utworzyć. Naturalną odpowiedzią było wyłączenie tej funkcji. CVE-2026-16723 omija to założenie w określonym środowisku Spring Boot: parser może dotrzeć do niebezpiecznej ścieżki podczas rozwiązywania typów dostępnych w strukturze wykonywalnego JAR-a.

Nie oznacza to, że każda aplikacja z Fastjson natychmiast daje napastnikowi powłokę. Potrzebny jest kontrolowany przez niego JSON, odpowiedni układ klas i wskazane warunki wdrożeniowe. Z punktu widzenia zarządzania ryzykiem nie należy jednak czekać na potwierdzenie dokładnej ścieżki w każdym serwisie. Aktywna eksploatacja oraz możliwość zdalnego wykonania kodu przesuwają takie systemy na początek kolejki.

Co nie jest objęte tym scenariuszem

Zgodnie z biuletynem producenta ten konkretny wariant nie dotyczy:

• Fastjson 2;
• aplikacji z globalnie włączonym SafeMode;
• specjalnych wydań Fastjson 1.x z sufiksem _noneautotype;
• wdrożeń, które nie korzystają z wykonywalnego pakietu Spring Boot fat JAR;
• wersji Fastjson 1.x spoza wskazanego zakresu 1.2.68–1.2.83.

To lista warunków dla CVE-2026-16723, a nie ogólne świadectwo bezpieczeństwa starej gałęzi. Fastjson 1.x jest linią historyczną i ma za sobą wiele problemów z deserializacją. Długoterminowym rozwiązaniem pozostaje migracja, nawet jeśli bieżący test wykaże, że dana instancja nie spełnia wszystkich warunków ataku.

Plan działania na dziś

1. Znajdź realne użycie biblioteki

Przeszukaj pliki pom.xml, build.gradle, lockfile’e, obrazy kontenerów, manifesty SBOM i zbudowane artefakty. Nie ograniczaj się do zależności bezpośrednich: Fastjson może przychodzić tranzytywnie. Potwierdź wersję w artefakcie wdrożonym na produkcji, bo deklaracja w repozytorium i zawartość uruchomionego JAR-a mogą się różnić.

2. Włącz SafeMode jako zabezpieczenie awaryjne

Alibaba zaleca globalne włączenie SafeMode, między innymi właściwością JVM:

-Dfastjson.parser.safeMode=true

Można też użyć globalnej konfiguracji biblioteki. Zmianę trzeba przetestować, ponieważ może wpłynąć na kod, który legalnie polegał na dynamicznym rozwiązywaniu typów. Nie ustawiaj flagi tylko w jednym kontrolerze — zabezpieczenie ma obejmować wszystkie ścieżki deserializacji w procesie.

3. Rozważ wydanie noneautotype

Jeżeli natychmiastowa migracja jest niemożliwa, producent wskazuje artefakt com.alibaba:fastjson:1.2.83_noneautotype. Jest to ograniczenie ryzyka dla starej gałęzi, nie cel architektoniczny. Trzeba sprawdzić zgodność aplikacji i dopilnować, aby stary wariant biblioteki nie pozostał w obrazie równolegle.

4. Zaplanuj migrację do Fastjson 2

Fastjson 2 nie jest podatny na CVE-2026-16723 i ma odmieniony model bezpieczeństwa. Migracja wymaga testów kompatybilności, serializacji, formatów dat, niestandardowych konwerterów oraz wydajności. Powinna jednak dostać właściciela i termin, zamiast pozostać bezterminowym zadaniem „po incydencie”.

5. Sprawdź, czy luka nie została już użyta

Samo włączenie zabezpieczenia nie usuwa skutków wcześniejszego włamania. Dla publicznie dostępnych endpointów przyjmujących JSON przeanalizuj:

• nietypowe wyjątki deserializacji i błędy ładowania klas;
• procesy potomne uruchamiane przez JVM;
• nowe lub zmienione pliki w katalogach aplikacji i katalogach tymczasowych;
• niespodziewane połączenia wychodzące z serwera;
• dostęp do sekretów, tokenów chmurowych i danych konfiguracyjnych po potencjalnym czasie wejścia.

Jeśli telemetria wskazuje wykonanie kodu, izoluj host, zabezpiecz materiał dowodowy, rotuj sekrety dostępne dla procesu i przejdź przez pełny plan reagowania na incydenty. Nie publikujemy ładunku ani instrukcji eksploatacji — obrońcom do priorytetyzacji nie jest potrzebne odtwarzanie ataku na systemie produkcyjnym.

Jak ograniczyć podobne ryzyko na przyszłość

Deserializacja danych nieufnych powinna mieć własny threat model. Preferuj precyzyjne DTO bez pól Object, stosuj walidację schematu przed mapowaniem, ogranicz klasy dostępne parserowi i traktuj biblioteki serializacyjne jak komponenty wysokiego ryzyka. W CI warto blokować znane podatne wersje na podstawie SBOM, ale skaner zależności musi być połączony z informacją, gdzie dany komponent działa i czy endpoint jest osiągalny z internetu.

To dobry przykład, dlaczego priorytety nie powinny wynikać wyłącznie z CVSS. W procesie zarządzania podatnościami liczą się także aktywna eksploatacja, ekspozycja, uprawnienia procesu i wartość danych za aplikacją.

Najczęstsze pytania

Czy wyłączenie AutoType chroni przed CVE-2026-16723?
Nie w konfiguracji opisanej przez Alibaba. Luka została potwierdzona przy wyłączonym AutoType. Włącz SafeMode lub użyj wskazanego wydania noneautotype, a następnie zaplanuj migrację.

Czy wystarczy deserializować do konkretnej klasy?
Nie należy tego zakładać. Zagnieżdżone pola ogólnych typów mogą ponownie otworzyć dynamiczną ścieżkę. Przejrzyj cały model danych i wszystkie endpointy przyjmujące nieufny JSON.

Czy Fastjson 2 trzeba aktualizować z powodu tej luki?
Fastjson 2 nie jest objęty CVE-2026-16723. Nadal należy utrzymywać go w aktualnej wersji i testować konfigurację, ale ten konkretny biuletyn dotyczy Fastjson 1.x.

Czy po włączeniu SafeMode temat jest zamknięty?
Nie. SafeMode ogranicza możliwość dalszego wykorzystania, lecz nie odpowiada na pytanie, czy atak nastąpił wcześniej. Potrzebne są przegląd logów, hunting i — dla systemów spełniających warunki luki — plan migracji.

Wniosek

CVE-2026-16723 uderza w popularne założenie, że wyłączenie AutoType rozwiązuje problem niebezpiecznej deserializacji w Fastjson 1.x. Najrozsądniejsza kolejność to: inwentaryzacja, natychmiastowe włączenie SafeMode lub wariantu noneautotype, analiza śladów ataku i migracja do Fastjson 2. Jeżeli potrzebujesz potwierdzić ekspozycję aplikacji Java albo przeprowadzić analizę powłamaniową, porozmawiaj z zespołem BreachRoad.

---

Źródła: Alibaba — oficjalny biuletyn bezpieczeństwa Fastjson 1.x, ThreatBook — obserwowana aktywna eksploatacja, Imperva — analiza CVE-2026-16723.