Fastjson 1.x senza via d'uscita: quando le mitigazioni standard…

CVE-2026-16723 colpisce Fastjson 1.2.68-1.2.83 con CVSS 9.0. L'exploit non richiede AutoType né gadget, ma la patch 1.x manca. ThreatBook e CISA-ADP si contraddicono

Il 21 luglio 2026 Alibaba ha pubblicato un advisory di sicurezza per CVE-2026-16723, una vulnerabilità di esecuzione remota critica nel parser JSON Fastjson 1.x. Il punteggio CVSS 9.0 e la natura dell'exploit — che funziona con le impostazioni predefinite, senza AutoType abilitato e senza gadget nel classpath — hanno immediatamente reso insufficenti le mitigazioni convenzionali. La conseguenza più grave: al 25 luglio 2026 non esiste alcuna patch per il ramo 1.x.

Punti chiave

CVE-2026-16723 colpisce Fastjson dalla versione 1.2.68 alla 1.2.83 inclusa con un punteggio CVSS 9.0 assegnato da Alibaba.
L'exploit non richiede AutoType abilitato né la presenza di gadget nel classpath, funzionando con la configurazione predefinita del parser.
La catena di attacco sfrutta il meccanismo di lookup delle risorse di classe tramite @type, con l'annotazione @JSONType che agisce come segnale di fiducia per bypassare i controlli successivi.
ThreatBook ha riportato exploitation in-the-wild dal 22 luglio 2026; CISA-ADP ha contrassegnato exploitation come "none" il 23 luglio, creando una discrepanza non risolta nelle fonti disponibili.

Il meccanismo che rompe il modello di fiducia di Fastjson

Il nucleo della vulnerabilità risiede in ParserConfig.checkAutoType, il metodo che Fastjson utilizza per gestire l'annotazione @type nei payload JSON. Secondo l'analisi di The Hacker News basata sull'advisory Alibaba, il parser converte il valore controllato dall'attaccante in un nome di risorsa di classe e lo passa a ClassLoader.getResourceAsStream(). In ambienti Spring Boot con fat-JAR eseguibili, questo permette l'uso di URL assolute per scaricare classi remote.

L'elemento critico è il ruolo dell'annotazione @JSONType nel bytecode scaricato. Fastjson legge questa annotazione tramite ASM ClassReader e la tratta come segnale di fiducia, consentendo il caricamento della classe prima che i controlli di sicurezza successivi intervengano. Questo ordine delle operazioni — load prima del check completo — è la condizione che permette l'esecuzione.

Su JDK moderni, la catena utilizza /proc/self/fd per riaprire JAR temporanei scaricati, un percorso che sfrutta la semantica dei file descriptor del sistema operativo. Questo dettaglio è documentato da The Hacker News come parte della descrizione dell'advisory Alibaba.

"no AutoType enablement required, no classpath gadget required" — Alibaba advisory via NVD/CVE-2026-16723

Analisi tecnica: le assunzioni secondo WeeX/GCSA

Un'analisi tecnica separata condotta da WeeX/GCSA Global Cybersecurity Alliance descrive come CVE-2026-16723 invalidi tre assunzioni difensive consolidate nella gestione di Fastjson. La prima: che la disabilitazione di AutoType renda il parser sicuro. La seconda: che il binding a un tipo fisso protegga dal caricamento di classi arbitrarie. La terza: che l'assenza di gadget noti nel classpath impedisca la costruzione di catene di exploit.

Questa analisi proviene da una fonte con ruolo di supporting e internal ID diverso (FJ-GETRESOURCE-RCE), non dalla fonte primaria della notizia dell'exploit in-the-wild. I dettagli tecnici di riproduzione — inclusa la conferma su JDK 8, 17, 21 e 25 con Spring Boot Loader in ambienti isolati — sono documentati in questa analisi separata, non in The Hacker News.

La condizione di Spring Boot fat-JAR è specifica ma non marginale. I deployment affetti sono quelli che utilizzano il formato eseguibile con loader integrato; i plain JAR non fat, gli uber-JAR generici e i WAR per Tomcat/Jetty non presentano la stessa superficie d'attacco. Questa granularità tecnica è fondamentale per l'inventario del rischio.

L'attività in-the-wild e la discrepanza CISA-ADP

La notizia dell'exploit in-the-wild si basa su dichiarazioni di ThreatBook e Imperva riportate da The Hacker News. Non esiste riscontro indipendente diretto con Alibaba né evidenza di compromissioni verificate.

ThreatBook ha dichiarato il 22 luglio 2026 di aver catturato exploitation in-the-wild dopo aver aggiunto il supporto di rilevamento due giorni prima. Imperva ha riportato attività contro servizi finanziari, healthcare, computing, retail e altri settori, principalmente negli Stati Uniti, con volumi minori a Singapore e Canada. Circa il 30% delle richieste proviene da tool Ruby e Go, con il restante da impersonatori di browser.

Allo stesso tempo, CISA-ADP ha contrassegnato exploitation come "none" il 23 luglio 2026. La vulnerabilità non è nel catalogo KEV. Nessun vendor ha pubblicato conteggi di attacchi, evidenza di esecuzione su target reali, o vittime confermate. Questa discrepanza è irrisolta nelle fonti disponibili.

Cosa fare adesso

Attivare SafeMode con -Dfastjson.parser.safeMode=true: i check di SafeMode sono posizionati prima dell'accesso alle risorse, interrompendo la catena di exploit.
Inventariare tutte le dipendenze transitive che includono Fastjson 1.x nei progetti Spring Boot, verificando il formato di packaging dei JAR distribuiti.
Pianificare la migrazione a Fastjson2: il ramo 2.x non è affetto dalla vulnerabilità ed è l'unica linea di sviluppo attiva.
Verificare che non esistano istanze della build 1.2.83_noneautotype trattate come equivalenti alla release standard: solo la build con suffisso noneautotype ha restrizioni aggiuntive.

Il confine del supporto e la scelta forzata

La situazione è bloccativa per chi non può migrare rapidamente. La versione 1.2.83 è l'ultima release standard del ramo 1.x; non esiste una build patchata nel repository GitHub del progetto né in Maven Central al 25 luglio 2026.

L'analisi del codice sorgente condotta da GCSA indica che la logica di probing delle risorse di classe esiste almeno dalla 1.2.67, con la 1.2.68 segnata come punto di verifica confermato. Per le versioni precedenti alla 1.2.67, la fonte qualifica questa estensione come possibile ma non verificata. Alibaba non ha comunicato una timeline per un eventuale backport.

La decisione operativa per i team che mantengono Fastjson 1.x si presenta come scelta tra mitigazione immediata con SafeMode e migrazione strutturale a Fastjson2. La prima non richiede modifiche al codice ma impatta la funzionalità del parser. La seconda elimina la vulnerabilità ma richiede refactoring e testing di compatibilità. Entrambe le opzioni sono valide; nessuna terza via esiste al momento.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti