CVE-2025-55182 (React2Shell): cosa è successo e cosa insegna

Il 3 dicembre 2025 il team di React ha pubblicato un avviso di sicurezza. Due giorni dopo, i primi tentativi di sfruttamento erano già visibili nei sistemi di monitoraggio. Entro una settimana la vulnerabilità era nel catalogo delle falle sfruttate attivamente tenuto dall’agenzia federale statunitense per la cybersicurezza, e diversi gruppi criminali la stavano usando in campagne distinte.

Si chiama CVE-2025-55182, ha ricevuto il soprannome React2Shell — costruito sul precedente di Log4Shell — e ha ottenuto il punteggio massimo possibile nella scala di gravità: 10.0.

A distanza di mesi resta un caso da studiare, e non per la vulnerabilità in sé. Le patch sono disponibili da subito e chi le ha applicate ha chiuso il problema in un pomeriggio. Il punto interessante è emerso durante quella settimana, quando molte aziende hanno scoperto due cose insieme: che stavano usando un componente di cui non sapevano nulla, e che gli strumenti con cui hanno controllato dicevano il falso.

1. Cos’è e cosa colpisce
2. Perché ha preso 10 su 10
3. La dipendenza che non sapevate di avere
4. Quando lo scanner dice che siete a posto
5. Cosa è successo dopo l’accesso
6. Cosa resta di questa vicenda

Cos’è e cosa colpisce

React2Shell è un difetto nel modo in cui i React Server Components trasformano i dati ricevuti dalla rete in oggetti JavaScript. Il meccanismo coinvolto è il protocollo interno che React usa per scambiare le strutture dei componenti fra client e server: il decoder lato server accettava quei dati senza validarli adeguatamente, e da lì si arrivava all’esecuzione di codice.

Le versioni interessate sono React 19.0, 19.1.0, 19.1.1 e 19.2.0. Le correzioni sono uscite come 19.0.1, 19.1.2 e 19.2.1 sui pacchetti lato server.

Fin qui sembra un problema circoscritto a chi usa React 19 con i Server Components. Non lo era, e questa è la parte che conta: i framework costruiti sopra i React Server Components ereditano la stessa logica di deserializzazione, quindi risultavano esposti anche Next.js, React Router e altri. Chi non ha mai scritto una riga con quelle API si è trovato vulnerabile perché il framework le usava per lui.

Perché ha preso 10 su 10

Il punteggio massimo nella scala di gravità non si assegna spesso, e le ragioni qui sono tre.

L’ultima riga è quella che separa una vulnerabilità grave da un’emergenza. Molte falle critiche richiedono una configurazione particolare, e in pratica riguardano una minoranza delle installazioni. Qui no: era sufficiente eseguire una versione affetta nella sua configurazione normale. Se volete il quadro di come si pesano queste caratteristiche, e perché il punteggio di gravità da solo non basta a stabilire una priorità, il ragionamento è in CVSS, EPSS e CISA KEV.

La dipendenza che non sapevate di avere

Nei giorni successivi all’avviso, la domanda che circolava fra i team tecnici non era come applicare la patch. Era più elementare: siamo interessati o no?

Il motivo è la struttura delle applicazioni moderne. Installate un framework, quello porta con sé le proprie dipendenze, che a loro volta ne portano altre. Il risultato è che il componente vulnerabile può stare a tre livelli di distanza da qualunque scelta consapevole. Nessuno nel team ha deciso di usare i React Server Components; sono arrivati come parte del pacchetto.

Se questo suona familiare è perché è la stessa dinamica di Log4Shell nel 2021, e il soprannome della vulnerabilità è un riferimento diretto. In entrambi i casi il problema pratico non è stato correggere, ma sapere dove correggere.

C’è poi una seconda dimensione, che tocca il perimetro esterno. Le vostre applicazioni non sono le sole a contare: se un fornitore vi eroga un servizio attraverso un’applicazione web, la sua esposizione diventa un vostro problema operativo. È una delle voci che vale la pena tenere nel questionario di sicurezza fornitori, formulata come domanda concreta anziché come dichiarazione generica.

Quando lo scanner dice che siete a posto

Questo è l’episodio più istruttivo di tutta la vicenda, ed è passato quasi inosservato.

Nei giorni dell’emergenza sono comparsi in rete diversi strumenti per verificare rapidamente la propria esposizione. Alcuni funzionavano. Altri restituivano un esito negativo su sistemi che erano vulnerabili — lo hanno documentato i ricercatori di Trend Micro. Nello stesso periodo circolavano codici di attacco che dichiaravano di sfruttare la falla senza riuscirci, e che quindi producevano lo stesso effetto: la conferma sbagliata di essere al sicuro.

Un falso negativo è peggio di nessuna verifica. Chi non controlla resta nell’incertezza e continua a cercare; chi riceve un esito rassicurante chiude la questione e passa ad altro. Il risultato è un sistema esposto con un team convinto del contrario, che è precisamente la condizione in cui un attaccante preferisce trovarvi.

Da qui una conseguenza generale che vale oltre questo caso specifico. Uno strumento di verifica ha valore in proporzione a quanto è verificabile la sua metodologia: chi lo mantiene, cosa controlla esattamente, come distingue una presenza da un’esposizione effettiva. È la differenza fra una scansione delle vulnerabilità condotta con criterio e un responso senza contesto, e non è una distinzione accademica: nel dicembre 2025 ha separato le aziende che hanno corretto da quelle che credevano di non doverlo fare.

Cosa è successo dopo l’accesso

Vale la pena guardare cosa hanno fatto gli attaccanti una volta dentro, perché smentisce un’idea diffusa: che una falla di questa gravità porti a conseguenze spettacolari.

Nella maggior parte dei casi osservati, no. Le analisi pubblicate da Google, Trend Micro e Sophos descrivono soprattutto software per la generazione di criptovaluta, strumenti per mantenere l’accesso, tunnel per uscire dalla rete e strumenti di controllo remoto — inclusi framework legittimi per attività di red team riutilizzati in modo malevolo, come già visto con Cobalt Strike. Sono campagne opportunistiche: si scansiona su larga scala, si entra dove si può, si monetizza in modo silenzioso.

Alcuni ricercatori hanno collegato una parte di queste attività a gruppi statuali, ma le attribuzioni sono state presentate con cautela e altri analisti non le hanno confermate. È il comportamento corretto: su una vulnerabilità sfruttata da decine di attori contemporaneamente, distinguere chi ha fatto cosa è genuinamente difficile.

La ragione per cui questo conta per voi è la assenza di sintomi evidenti. Un software che produce criptovaluta consuma risorse e nulla più: nessun riscatto, nessun file cifrato, nessuna schermata di avviso. Si nota guardando i consumi anomali e il traffico in uscita, cioè cercandolo. Sul cosa cercare, l’articolo sugli indicatori di compromissione spiega la logica.

Cosa resta di questa vicenda

Le patch sono uscite lo stesso giorno dell’avviso, quindi la vulnerabilità in sé non è più la notizia. Restano tre cose utili.

La prima è che l’inventario batte la velocità di reazione. Un’azienda che sa quali componenti e quali versioni ha in produzione applica la correzione in poche ore; una che non lo sa impiega giorni solo per capire se il problema la riguarda, e in quei giorni le scansioni automatiche stanno già girando. Le vulnerabilità sfruttate prima che esista una difesa — quelle che l’articolo sugli exploit zero-day descrive — sono un problema diverso e più raro. React2Shell no: era corretta e documentata dal primo giorno.

La seconda è che questa categoria di difetto non è un’anomalia. La deserializzazione non sicura appartiene a una famiglia nota, censita da anni sia nella OWASP Top 10 sia nella classifica CWE degli errori più critici. La domanda utile non è quindi se React è sicuro, ma quante altre applicazioni nel vostro perimetro elaborano input non fidato senza validarlo.

La terza riguarda il modo di verificare. Sapere che una versione è affetta è un’informazione documentale: la ottenete confrontando un elenco. Sapere se la vostra applicazione è realmente attaccabile in quel punto è un’informazione sperimentale, e la ottenete solo provando. È la distinzione fra vulnerability assessment e penetration test, ed è anche il motivo per cui un’analisi dinamica sull’applicazione in esecuzione, come il DAST, vede cose che un controllo delle dipendenze non può vedere.