C'è una vulnerabilità critica sfruttata attivamente in rete per la quale non esiste una patch — e con ogni probabilità non esisterà mai. Riguarda Fastjson 1.x, una delle librerie Java più diffuse al mondo per la serializzazione JSON, sviluppata da Alibaba e scaricata milioni di volte da Maven Central. La falla, identificata come CVE-2026-16723 (CVSS 9,0), consente l'esecuzione di codice remoto senza autenticazione sulle applicazioni Spring Boot che incorporano le versioni vulnerabili della libreria. E poiché il ramo 1.x non è più mantenuto, l'unica difesa è la mitigazione.

I fatti

La vulnerabilità è stata resa nota da Alibaba il 21 luglio, con il credito al ricercatore Kirill Firsov di FearsOff Cybersecurity. Colpisce le versioni di Fastjson dalla 1.2.68 alla 1.2.83 quando la libreria è impacchettata dentro un eseguibile Spring Boot (il classico «fat-JAR») e la modalità protetta SafeMode è disattivata — che è la configurazione predefinita.

Le condizioni di sfruttamento sono le peggiori possibili: nessuna autenticazione, nessuna interazione dell'utente, e — a differenza delle storiche catene di attacco contro Fastjson — nessuna necessità di librerie «gadget» esterne né del flag AutoType abilitato. Basta una richiesta JSON opportunamente costruita per indurre l'applicazione a caricare ed eseguire codice fornito dall'attaccante. Entro il 25 luglio sia ThreatBook sia Imperva avevano confermato lo sfruttamento attivo contro bersagli in produzione.

Il problema: la 1.x non riceverà correzioni

Fastjson 1.x non è più attivamente mantenuta: lo sviluppo si è spostato da tempo su fastjson2, che non è vulnerabile. Al momento della scoperta non esisteva alcun artefatto corretto del ramo 1.x né tra i tag GitHub del progetto né su Maven Central — e nulla lascia pensare che arriverà. È lo scenario che i gestori del rischio chiamano «forever-day»: una falla critica destinata a restare aperta finché la dipendenza non viene sostituita.

Analisi: il rischio silenzioso che vive nelle dipendenze

Il paragone che viene in mente è Log4Shell, e per certi versi la situazione è più insidiosa. Nel 2021 Log4j ricevette una patch in pochi giorni; qui la patch non c'è. Come allora, il problema non è «un software che avete installato» ma una libreria sepolta in profondità negli alberi di dipendenze: un gestionale sviluppato da una software house, un middleware di integrazione, un applicativo bancario o della PA costruito anni fa da un fornitore che magari non esiste più. Chi la usa spesso non sa di usarla.

C'è anche una lezione di design: SafeMode esiste proprio per bloccare questa classe di attacchi, ma è disattivata per impostazione predefinita. È l'ennesimo caso di «insecure by default» in cui la configurazione sicura è opzionale e quella comoda è lo standard.

Cosa significa per le aziende italiane

L'ecosistema Java/Spring Boot è ovunque nell'IT enterprise italiano: core bancari, gestionali, portali della pubblica amministrazione, piattaforme di integrazione. Fastjson è particolarmente diffusa nei prodotti di origine asiatica, ma compare anche in software occidentali e in progetti interni che l'hanno adottata per le sue prestazioni. Per le software house italiane che mantengono applicazioni legacy la domanda è immediata: quali dei nostri prodotti la includono, e in quale versione?

Sul piano normativo, la NIS2 impone ai soggetti essenziali e importanti la gestione delle vulnerabilità e la sicurezza della catena di approvvigionamento (art. 21): una libreria non mantenuta e sfruttata attivamente dentro un applicativo di un fornitore rientra esattamente in questo perimetro, e legittima richieste formali di verifica ai fornitori stessi. Se lo sfruttamento porta a esfiltrazione di dati personali, scatta la notifica al Garante entro 72 ore ai sensi del GDPR, oltre agli obblighi verso ACN/CSIRT Italia per i soggetti NIS2.

Cosa fare subito

  • Verificare la presenza di Fastjson 1.x nei propri progetti: mvn dependency:tree o gradle dependencies, cercando versioni tra 1.2.68 e 1.2.83.
  • Ispezionare anche i fat-JAR di terze parti: la presenza del percorso com/alibaba/fastjson dentro l'archivio è il segnale da cercare.
  • Attivare subito SafeMode dove la libreria non può essere rimossa: parametro -Dfastjson.parser.safeMode=true alla JVM (o attivazione via codice/proprietà). Attenzione: disabilita l'AutoType, quindi va testato.
  • Pianificare la migrazione a fastjson2 o a un'alternativa mantenuta (Jackson, Gson): è l'unica soluzione definitiva.
  • Chiedere ai fornitori software conferma scritta sull'eventuale presenza della libreria nei loro prodotti e sulle mitigazioni applicate.
  • Proteggere il perimetro con WAF e regole contro payload JSON anomali, e monitorare le JVM per comportamenti sospetti: processi figli inattesi, connessioni in uscita verso host sconosciuti.

Quando una libreria muore ma il suo codice continua a girare in produzione, il debito tecnico diventa debito di sicurezza. Questo è il momento giusto per saldarlo.