Nel campo delle applicazioni Web, uno degli obiettivi primari è migliorare le prestazioni e l’esperienza utente. Le React Server Components (RSC) rappresentano un’evoluzione significativa nel modo in cui le applicazioni Web moderne gestiscono il rendering e la logica lato client e server. Spostando sul server alcune operazioni che tradizionalmente erano eseguite lato browser, le RSC aprono anche nuovi vettori di attacco. React2Shell, la vulnerabilità critica recentemente scoperta (CVE-2025-55182), sfrutta questa superficie per consentire l’esecuzione di codice da remoto: un po’ come avvenne con Log4Shell nel 2021, è un campanello d’allarme sull’importanza di proteggere la logica server-side nelle applicazioni.
Cosa sono e cosa fanno le React Server Components (RSC)
Le RSC offrono diversi vantaggi permettendo di:
- Ridurre il carico di JavaScript sul client, migliorando i tempi di caricamento e la reattività dell’interfaccia.
- Eseguire elaborazioni e accesso ai dati lato server, senza esporre direttamente database o API al client.
- Ottimizzare il rendering dinamico, combinando parti di pagina pre-renderizzate con componenti interattive caricate lato browser solo quando necessario.
Sono caratteristiche che hanno reso le RSC centrali in framework come Next.js e sono oggi utilizzate in applicazioni Web ad alta scala: e-commerce, piattaforme SaaS, strumenti collaborativi, e persino servizi finanziari ed enterprise.
Per funzionare, però, le RSC si basano su un meccanismo sofisticato: il protocollo Flight, che “serializza” e trasporta componenti React dal server al client. È proprio qui che nasce React2Shell, una falla che ha scosso l’intero settore.
Cos’è la vulnerabilità React2Shell
Alla base di React2Shell c’è un problema profondo e insidioso: la deserializzazione non sicura dei payload trasmessi tramite il già citato protocollo Flight, sistema che permette alle RSC di trasferire strutture dati complesse dal server al client in modo incrementale.
Un pacchetto Flight alterato o contraffatto può indurre il server a:
- Ricostruire in memoria oggetti manipolati dall’attaccante.
- Invocare funzioni non previste dal modello di sicurezza.
- Attraversare i confini tra componenti client e server.
- Eseguire codice proveniente da input non attendibili.
Il risultato finale è che l’attaccante può indurre il server a eseguire operazioni arbitrarie, spesso fino all’esecuzione di codice arbitrario in modalità remota (RCE, Remote Code Execution), senza necessità di esporre manualmente funzionalità pericolose.
Concetto chiave: deserializzazione sicura vs non sicura
Serializzazione: significa trasformare oggetti/strutture in una sequenza di byte o testo (JSON, binary) per poterli inviare su rete o salvare.
Deserializzazione: ricostruire in memoria gli oggetti a partire dalla sequenza ricevuta.
Deserializzazione non sicura: avviene quando il codice che ricostruisce gli oggetti assume implicitamente che i dati ricevuti siano benigni e ricrea strutture o comportamenti che dovrebbero essere invece considerati non fidati. Il risultato è che si possono ricreare oggetti con metodi, prototipi o riferimenti che innescano l’esecuzione di codice arbitrario. Proprio come nel caso di React2Shell.
Decine di migliaia di endpoint vulnerabili e prime compromissioni
La vulnerabilità critica React2Shell sta rapidamente diventando uno degli incidenti di sicurezza più significativi del 2025. A poche ore dalla divulgazione pubblica, i principali osservatori della sicurezza globale hanno rilevato una massiccia ondata di scansioni, tentativi di sfruttamento e compromissioni reali contro infrastrutture basate su RSC e framework come Next.js, che ereditano la stessa logica di deserializzazione vulnerabile.
Secondo le prime analisi, oltre 77.000 indirizzi IP esposti su Internet risultano vulnerabili, mentre più di 30 organizzazioni sono già state compromesse, in attacchi attribuiti anche a gruppi APT sponsorizzati da enti statali.
GreyNoise, che mette a disposizione uno strumento per verificare l’attività di rete generata dai singoli indirizzi IP, ha registrato 181 IP unici coinvolti nelle scansioni delle ultime 24 ore. I principali Paesi di origine del traffico malevolo sono Paesi Bassi, Cina, Stati Uniti e Hong Kong. Il volume, la ripetitività e la natura automatizzata del traffico indicano chiaramente un’ondata di ricognizione su scala globale.
I ricercatori osservano che gli aggressori iniziano con semplici operazioni matematiche eseguite via PowerShell, dopo aver sfruttato la falla React2Shell. La possibilità di eseguire comandi come powershell -c "40138*41979", conferma la capacità di eseguire codice, non genera output sospetti nei log, minimizza gli indicatori di compromissione.
Una volta verificata la vulnerabilità, gli aggressori installano payload tramite comandi codificati in Base64: powershell -enc <base64>.
Raccomandazioni per le realtà aziendali
Le imprese che utilizzano RSC e framework compatibili devono aggiornare immediatamente React alla versione più recente, ricompilare e ridistribuire le applicazioni, analizzare attentamente i log alla ricerca di comandi PowerShell anomali, chiamate sospette a shell, traffico verso indirizzi non riconosciuti.
È inoltre bene rafforzare i controlli di sicurezza, usare Windows Application Firewall (WAF) aggiornati, EDR con capacità anti-offuscamento, logging dettagliato delle chiamate server-side, valutare possibili compromissioni se l’applicazione è stata esposta anche solo per poche ore dopo la divulgazione della falla.
Nonostante la disponibilità di strumenti di scanning efficaci — ad esempio quelli pubblicati da Assetnote — gli esperti avvertono che alcuni provider applicano protezioni a runtime, non semplici regole WAF e che questi meccanismi possono proteggere anche installazioni che appaiono vulnerabili ai tool di scanning.
Il consiglio unanime è aggiornare immediatamente qualora si avessero dubbi.