Security Weekly: React2Shell
Approfondiamo il tema per conoscere, rilevare e mitigare questa CVE da 10/10
📬 Ben ritrovato caro cyber User. In questa puntata parliamo di React2Shell (CVE-2025-55182), una vulnerabilità che ridefinisce il concetto di rischio nell’ecosistema JavaScript moderno.
Non stiamo parlando di un semplice bug, ma di una falla di “unsafe deserialization” (deserializzazione non sicura) con il punteggio massimo di gravità: CVSS 10.0.
Il problema risiede nel cuore dei React Server Components (RSC). Se la tua applicazione utilizza React 19.x o Next.js 15.x / 16.x con l’App Router, sei potenzialmente esposto. Il dettaglio più allarmante? Non è necessario che tu stia utilizzando esplicitamente le “Server Functions”; è sufficiente che l’applicazione supporti i Server Components affinché un attaccante possa eseguire codice arbitrario (RCE) da remoto senza alcuna autenticazione.
Come funziona l’exploit
React utilizza un protocollo chiamato “Flight Protocol” per serializzare i dati e trasmetterli tra server e client. L’exploit React2Shell non è un singolo errore, ma una catena sofisticata di manipolazioni che trasforma questo flusso di dati in un’arma.
Ecco una “Kill Chain” tecnica:
Path Traversal e Prototype Chain: l’attaccante invia un payload che abusa della risoluzione dei riferimenti. Utilizzando una stringa come
$1:constructor:constructor, riesce a risalire la catena dei prototipi dell’oggetto fino a ottenere l’accesso al costruttore globaleFunction. Questo è il primo passo per trasformare una stringa in codice eseguibile.Fake Chunk Injection (l’inganno): il server React si aspetta dei “chunk” (pezzi di dati) validi. L’attaccante inietta un oggetto JSON contraffatto (un “fake chunk”) che contiene un riferimento circolare a se stesso (es.
$@0). Impostando attributi specifici come“status”: “resolved_model”e unthenmalevolo ($1:__proto__:then), l’attaccante inganna il server facendogli trattare questo oggetto falso come un componente React legittimo pronto per essere processato.Abuso dell’handler
$B: il colpo di grazia avviene sfruttando un gestore interno del protocollo destinato ai Blob binari, identificato dal prefisso$B. L’attaccante costringe il server a passare il suo payload (che ora punta al costruttoreFunctionottenuto al passo 1) attraverso questo handler. Il risultato? Il server esegue ciecamente il codice JavaScript fornito dall’attaccante, comeFunction(”return process.mainModule.require(’child_process’).execSync(’calc’)”).
💡 Infografica
Scenario di minaccia: la “tempesta” in corso
Non si tratta di teoria. Gli attacchi sono iniziati il 3 dicembre 2025, poche ore dopo la divulgazione pubblica della falla.
Gli attori: Amazon ha identificato gruppi legati alla Cina, come Earth Lamia (noto per colpire logistica e finanza) e Jackpot Panda (sicurezza domestica asiatica), che stanno attivamente sfruttando la vulnerabilità.
Modus operandi “quantità su qualità”: molti attaccanti stanno usando exploit pubblici (PoC) “rotti” o incompleti, generando molto rumore nei log senza successo. Tuttavia, questo approccio volumetrico garantisce che le configurazioni vulnerabili vengano prima o poi trovate.
Debugging in tempo reale: è stato osservato un comportamento inquietante. Un attaccante (IP 183.6.80.214) ha passato quasi un’ora a “debuggare” manualmente un exploit contro un target vivo, provando comandi come
whoami, leggendo/etc/passwde tentando di scrivere file in/tmp/pwned.txt. Questo dimostra che dietro gli script automatici ci sono operatori umani pronti a perfezionare l’attacco.
Il dilemma della difesa: perché i WAF falliscono
Affidarsi solo al Web Application Firewall (WAF) per questa vulnerabilità è pericoloso.
Il problema della codifica (encoding): i WAF basati su firme (pattern matching) cercano parole chiave come
constructorochild_process. Tuttavia, l’attaccante può codificare il payload in infiniti modi validi per JavaScript ma invisibili al WAF (es. Unicode escapes\u0063onstructoroString.fromCharCode(...)). Il WAF vede byte codificati, ma l’applicazione React li decodifica ed esegue.Bypass dei limiti di ispezione:
Padding: i WAF spesso ispezionano solo i primi 8KB-64KB della richiesta. Aggiungendo dati “spazzatura” all’inizio del body, l’attaccante spinge il payload malevolo oltre l’area di ispezione.
Chunked transfer: spezzando il payload malevolo (es. dividendo la stringa
$@in due pacchetti separati) tramite Chunked Transfer Encoding, è possibile evadere i controlli che non riassemblano l’intero stream prima dell’analisi.
💡 Infografica
Action Plan: cosa fare subito
L’unica difesa reale è l’aggiornamento, poiché i WAF possono essere aggirati.
Patching immediato: aggiorna alle versioni sicure che introducono controlli di tipo e bloccano l’accesso ai prototipi:
React: aggiornare a 19.0.1+, 19.1.2+, o 19.2.1+.
Next.js: aggiornare a 15.0.5+, 15.1.9+, 15.2.6+, o 16.0.7+.
Rilevamento (IoC): controlla i log per questi indicatori:
Header HTTP:
next-actionorsc-action-id.Body della richiesta: presenza di pattern come
$@o“status”:”resolved_model”.Comportamento anomalo: tentativi di lettura di
/etc/passwdo creazione di file in/tmp/.
Scanning Intelligente: utilizza strumenti specifici come lo scanner di Assetnote o Fatguru. Questi tool possono rilevare se il protocollo RSC è esposto controllando il
Content-Type: text/x-componento cercando specifici codici di errore di React 19, senza necessariamente lanciare un exploit distruttivo.
Assolutamente sì. La fase di detection è cruciale, specialmente perché, come abbiamo visto, i WAF tradizionali faticano a bloccare questi payload.
Ecco una proposta per un paragrafo dedicato alla “Caccia alle Streghe” (Detection & Hunting), strutturato per essere inserito nella tua newsletter. Risponde alla tua richiesta di usare strumenti come Nuclei e definisce una strategia di scansione a imbuto (dai sottodomini alla vulnerabilità).
Detection & Hunting: scovare React2Shell nella tua infrastruttura
Poiché l’attacco avviene prima dell’autenticazione e spesso aggira i log standard, è necessario un approccio attivo. La strategia migliore segue un modello a imbuto: Discovery dei sottodomini -> Identificazione del protocollo RSC -> Conferma della culnerabilità.
1. Fase di recon: mappare la superficie (Subdomain Enumeration)
Prima di lanciare exploit, devi sapere dove gira Next.js.
Strumenti: usa tool standard come Subfinder o Amass per enumerare tutti i sottodomini.
Il target: una volta ottenuta la lista, l’obiettivo è identificare quali host rispondono al protocollo React Server Components (RSC). Non limitarti a scansionare la root (
/), poiché Next.js spesso reindirizza la root alla pagina di login (307/308 Redirect), nascondendo la vulnerabilità agli scanner superficiali.
2. Scansione automatica con Nuclei
Per una scansione massiva e rapida, Nuclei è lo strumento ideale, ma richiede un template aggiornato.
Il template: il ricercatore fatguru ha rilasciato un template specifico (cve-2025-55182-detection.yaml) pensato per rilevare l’esposizione della superficie RSC senza necessariamente far crashare il server.
Comando:
nuclei -t cve-2025-55182-detection.yaml -l list_of_subdomains.txt
Cosa cerca: il template verifica se il server “parla” il protocollo RSC (cercando il content-type
text/x-component) e se risponde a payload specifici che generano errori di digest tipici di React 19.
3. Verifica approfondita: gli scanner specializzati
Se Nuclei accende una spia rossa, usa strumenti dedicati per confermare la gravità. Qui hai due opzioni principali a seconda dell’obiettivo:
Opzione A: Assetnote Scanner (verifica RCE) ideale per confermare se è possibile l’esecuzione di codice. Questo tool invia un payload che esegue una moltiplicazione matematica (
41*271). Se il server risponde con il risultato, la RCE è confermata.Feature utile: include una modalità
--safe-checkche usa canali laterali (codici di errore 500 specifici) invece di eseguire codice, per evitare danni in produzione.Comando:
python3 scanner.py -u https://target.com --safe-check
Opzione B: Fatguru Scanner (Surface Exposure) migliore per ambienti di produzione. Molti scanner falliscono perché tentano di caricare moduli come
child_processche sono bloccati dalserverManifestdi Next.js in produzione. Questo scanner invece:Sonda percorsi casuali (es.
/x7z9q2) per aggirare i redirect della home page e forzare l’attivazione dell’App Router.Rileva l’esposizione del protocollo anche se l’RCE diretta è bloccata, segnalando comunque un rischio critico da patchare.
4. Indicatori di Compromissione (IoC) nei log
Se non puoi scansionare attivamente, controlla i log del server per questi segnali di fumo:
Header: presenza di
next-actionorsc-action-idin richieste POST sospette.Body: stringhe come
$@(riferimenti circolari) o“status”:”resolved_model”.Attività: tentativi di lettura di
/etc/passwdo scrittura in/tmp/(spesso file chiamatipwned.txt).
Le fonti utili
Anche quest’oggi abbiamo concluso, ti ringrazio per il tempo e l’attenzione che mi hai dedicato, augurandoti buona settimana, ti rimando al mio blog e alla prossima settimana per un nuovo appuntamento con NINAsec.
Il network
Con questo piccolo schema riepilogo in breve i punti di riferimento che alimento con i miei contenuti, su diversi fronti, quasi quotidianamente.
Ransomfeed.it - piattaforma di monitoraggio ransomware, realtime;
inSicurezzaDigitale.com - blog di sicurezza informatica con approfondimenti tematici;
Cyber-News.it - portale italiano con i migliori contributi cyber dalle news quotidiane;
SecureBulletin.com - news internazionali su cyber security, analisi e frodi;
Spcnet.it - notizie geek;
ilGlobale.it - note politiche e di economia, di rilevanza internazionale;
Ziobudda.org - notizie Linux, open source e software libero, segnalabili e commentabili (socialnews).
DarioFadda.it - il raccoglitore di tutto questo, con un suo feed RSS generale, per non perdere niente di quello che pubblico.



