Fastjson espone una RCE critica senza patch nella versione 1.x

🛡️ Executive Summary

• CVE-2026-16723 consente RCE su Fastjson 1.2.68-1.2.83 in applicazioni Spring Boot fat-JAR con SafeMode disattivata.
• Un PoC separato concatena due corruzioni di memoria in Oj per eseguire comandi come utente git sui server GitLab vulnerabili.
• Fastjson richiede SafeMode o migrazione a Fastjson2; GitLab deve essere aggiornato almeno alle versioni 18.10.8, 18.11.5 o 19.0.2.

Due vulnerabilità nei parser JSON espongono applicazioni Java e server GitLab all’esecuzione remota di codice, ma con condizioni e livelli di rischio differenti. Fastjson 1.x, libreria sviluppata da Alibaba, presenta la falla critica CVE-2026-16723, già oggetto di tentativi di sfruttamento e priva di una nuova versione corretta nel ramo storico. Parallelamente, un ricercatore ha pubblicato un proof of concept che concatena due errori di memoria nella gemma Oj, utilizzata da GitLab per elaborare i diff dei notebook Jupyter. Nel primo caso l’attacco può avvenire senza autenticazione; nel secondo basta un normale account autorizzato a inserire file in un progetto.

Fastjson esegue codice con AutoType disabilitato

CVE-2026-16723 interessa Fastjson dalla versione 1.2.68 alla 1.2.83, compresa l’ultima release standard della serie 1.x. La vulnerabilità può essere sfruttata anche quando AutoType rimane disabilitato, contrariamente a molte precedenti catene di attacco contro la libreria, e non richiede la presenza di una gadget class già disponibile nel classpath. La condizione più importante riguarda invece il modello di distribuzione: l’applicazione deve essere eseguita come Spring Boot executable fat-JAR, normalmente avviato attraverso java -jar, e deve accettare dati JSON controllabili dall’esterno attraverso un percorso raggiungibile dalla rete. Anche SafeMode deve essere disattivata, impostazione che corrisponde al comportamento predefinito di Fastjson 1.x. L’avviso di sicurezza pubblicato da Alibaba conferma la riuscita della catena su Spring Boot 2.x, 3.x e 4.x e sulle versioni 8, 11, 17 e 21 del JDK. Gli entry point coinvolti comprendono JSON.parse, JSON.parseObject(String) e JSON.parseObject(String, Class). Specificare una classe di destinazione non costituisce una mitigazione sufficiente, perché il payload può essere annidato all’interno di campi dichiarati come Object o Map. Il problema riporta al centro il rischio delle dipendenze Java profonde, già emerso con Log4j e le librerie incorporate in migliaia di applicazioni, dove l’inventario del software diventa complesso quanto l’applicazione principale.

Una risorsa annidata aggira i controlli sui tipi

La falla nasce nel percorso utilizzato da Fastjson per risolvere il valore controllato dall’attaccante contenuto nella proprietà @type. In una distribuzione Spring Boot compatibile, il parser può trasformare il valore in una ricerca di risorse e raggiungere un file di classe inserito in un archivio JAR annidato. Il bytecode preparato dall’aggressore contiene un’annotazione @JSONType, che viene interpretata come un segnale di affidabilità e consente alla classe di superare i controlli previsti dalla libreria. Una volta caricata, la classe permette di eseguire codice con i privilegi del processo Java. La ricerca tecnica di FearsOff sulla RCE Fastjson descrive anche una variante adatta ai JDK più recenti, nella quale il server scarica un archivio remoto e lo richiama attraverso /proc/self/fd. La catena non funziona indistintamente su ogni applicazione Java: le normali distribuzioni WAR su Tomcat o Jetty, i JAR non strutturati come eseguibili Spring Boot e Fastjson2 non presentano lo stesso percorso vulnerabile. Le segnalazioni di attività ostile devono inoltre essere interpretate con cautela. ThreatBook e Imperva hanno rilevato richieste costruite per sondare la vulnerabilità contro organizzazioni finanziarie, sanitarie, tecnologiche e commerciali, soprattutto negli Stati Uniti, ma non hanno pubblicato prove sufficienti per dimostrare compromissioni riuscite o identificare vittime. Si può quindi parlare di tentativi di sfruttamento osservati, non di una campagna con intrusioni confermate su larga scala.

Fastjson 1.x resta senza una release corretta

Al 25 luglio 2026, Alibaba non ha pubblicato una nuova versione standard di Fastjson 1.x contenente una correzione specifica per CVE-2026-16723. La release 1.2.83, distribuita in passato come risposta ad altre debolezze AutoType, rientra essa stessa nell’intervallo vulnerabile. Le organizzazioni che non possono migrare immediatamente devono attivare SafeMode mediante la proprietà -Dfastjson.parser.safeMode=true, la configurazione globale di ParserConfig oppure il file fastjson.properties. Un’altra possibilità consiste nell’utilizzare la build com.alibaba:fastjson:1.2.83_noneautotype, nella quale il codice interessato viene eliminato durante la compilazione. La soluzione strutturale resta però il passaggio a Fastjson2, che adotta un modello allowlist-first e non utilizza la stessa combinazione tra resource probing e annotazioni considerate attendibili. I team devono cercare Fastjson non soltanto nei file Maven o Gradle principali, ma anche nelle dipendenze transitive, nelle immagini container e nei componenti distribuiti da fornitori esterni. I controlli di compromissione dovrebbero individuare valori @type anomali, riferimenti a JAR annidati o remoti, connessioni in uscita inattese, processi figli generati dalla JVM, webshell e modifiche ai file applicativi. La gestione ricorda le difficoltà affrontate con Spring4Shell e le applicazioni Java esposte a Internet: conoscere la presenza di una libreria non basta, perché la reale sfruttabilità dipende anche dalla modalità di packaging, dall’input raggiungibile e dalla configurazione del runtime.

GitLab espone l’utente git tramite notebook Jupyter

La seconda vulnerabilità riguarda GitLab CE ed EE self-managed e nasce da due errori nella libreria Oj, un parser JSON ad alte prestazioni scritto in larga parte in C e utilizzato dalle applicazioni Ruby. GitLab passa i file .ipynb controllati dagli utenti alla gemma interna ipynbdiff, incaricata di mostrare nel browser le differenze tra versioni dei notebook Jupyter. Il contenuto raggiunge Oj::Parser.usual.parse all’interno di un processo Puma persistente, portando dati appartenenti al repository direttamente nelle strutture di memoria native del parser. Secondo la ricerca GitLab Oj Spill di depthfirst, qualsiasi utente autenticato capace di effettuare un commit può caricare un notebook manipolato e aprirne il diff per avviare la catena. Non servono privilegi amministrativi, accesso ai runner CI/CD, interazione di un’altra vittima o capacità di scrivere nei progetti altrui. Il codice viene eseguito come utente di sistema git, identità utilizzata dai processi applicativi GitLab. Da quel contesto possono risultare accessibili repository, segreti Rails, token, credenziali di servizio, dati delle pipeline e servizi interni raggiungibili dall’istanza. Il rischio è particolarmente rilevante perché GitLab occupa una posizione centrale nella supply chain del software, come dimostrano gli attacchi contro repository e sistemi Git utilizzati per distribuire codice.

Due corruzioni di memoria producono la RCE

Il primo errore in Oj riguarda una scrittura fuori limite nella struttura utilizzata per tracciare la profondità degli array e degli oggetti JSON. Il parser dispone di uno stack fisso da 1.024 byte, ma incrementa la profondità senza un controllo adeguato, permettendo a un notebook fortemente annidato di sovrascrivere progressivamente campi interni e modificare il callback start. Il secondo problema interessa una chiave JSON lunga 65.565 byte, la cui dimensione viene troncata durante il passaggio attraverso un intero signed a 16 bit. Il valore risultante induce il parser a restituire dati sovrapposti a un puntatore heap ancora valido. GitLab mostra poi questo contenuto nel diff del notebook, trasformando l’errore in una divulgazione di memoria utile a superare ASLR. Combinando il puntatore esposto con la scrittura fuori limite, l’exploit individua le librerie caricate e reindirizza il callback verso system(). Il proof of concept pubblico è stato costruito per GitLab 18.11.3 su x86-64 e dipende da offset, stato dei registri e comportamento di jemalloc specifici di quell’immagine. Non rappresenta quindi un attacco immediatamente riutilizzabile contro qualsiasi installazione, ma dimostra in modo concreto la possibilità della RCE. I ricercatori non risultano a conoscenza di sfruttamenti reali, mentre GitLab avrebbe riprodotto autonomamente la catena prima di distribuire la correzione.

GitLab aveva classificato il fix come semplice bug

Le versioni vulnerabili comprendono GitLab 15.2.0-18.10.7, 18.11.0-18.11.4 e 19.0.0-19.0.1. Le prime release corrette sono rispettivamente 18.10.8, 18.11.5 e 19.0.2, tutte dotate di Oj 3.17.3. La correzione è stata pubblicata il 10 giugno 2026, ma l’aggiornamento della gemma Oj è comparso tra i bug fix ordinari e non nella tabella dedicata alle vulnerabilità. Non sono stati assegnati un codice CVE o un punteggio CVSS alla catena specifica, circostanza che potrebbe avere indotto alcuni amministratori a non considerare urgente l’aggiornamento. Il PoC è arrivato pubblicamente il 24 luglio, rendendo ora molto più rischioso mantenere una versione non corretta. Gli amministratori devono verificare la release GitLab realmente eseguita nel container Webservice, soprattutto nelle installazioni distribuite mediante Helm o GitLab Operator, senza affidarsi esclusivamente alla versione del chart. Non risultano workaround alternativi: le linee fuori dal supporto devono essere portate a una release mantenuta. Il caso dimostra che la classificazione editoriale di una patch può influire quanto la disponibilità della correzione. Un aggiornamento tecnicamente efficace, ma presentato come manutenzione ordinaria, rischia di rimanere escluso dai processi di prioritizzazione basati su CVE, severità e bollettini ufficiali.