TL; DR
React2Shell (CVE-2025-55182) crea una critica rischio RCE operanti in Componenti del server React (RSC) e framework che li incorporano, tra cui Next.js. Perché la vulnerabilità vive dentro di noi RSC livello di serializzazione e deserializzazione, gli aggressori possono inviare una richiesta HTTP contraffatta e innescare esecuzione di codice remoto non autenticato, anche quando i team eseguono configurazioni framework predefinite. Next.js le applicazioni sono quelle che presentano la maggiore esposizione perché accettano ed elaborano Volo di reazione payload tramite HTTP per impostazione predefinita.
Il difetto interessa più versioni di Pacchetti server Reacte gli aggressori non hanno bisogno di una logica applicativa personalizzata per sfruttarla. I ricercatori di sicurezza mostrano un'affidabilità prossima al 100% e le prime scansioni rivelano che molti ambienti cloud sono vulnerabili Next.js le istanze. Le squadre devono applicare la patch immediatamente e convalidare il loro intero ecosistema per ridurre il Rischio RCE di React2Shell (CVE-2025-55182).
Una vulnerabilità critica segnalata tramite il programma bug bounty di Meta il 29 novembre ha innescato risposte urgenti nell'intero ecosistema JavaScript.
Designato CVE-2025-55182, divulgato il 3 dicembre ora denominato React2Shell è una vulnerabilità di massima gravità che ha un impatto Componenti del server React insieme ai framework che li incorporano. Inizialmente, è stato assegnato un identificatore di vulnerabilità Next.js separato (CVE-2025-66478), ma l'NVD lo ha successivamente consolidato nel CVE primario di React come voce duplicata.
Il problema di fondo è la stessa gestione non sicura dei payload RSC serializzati che possono essere attivati tramite una richiesta HTTP. Questo apre la porta a un malintenzionato che può inviare una richiesta HTTP manipolata che determina l'esecuzione di codice JavaScript arbitrario sul server dopo essere stato deserializzato da React.
CVE-2025-55182 Panoramica
I componenti React Server sono profondamente integrati nei framework moderni e, in molti casi, sono abilitati di default. Per questo motivo, le applicazioni possono essere esposte a React2Shell (CVE-2025-55182) anche se non definiscono mai esplicitamente un endpoint della funzione server. L'implementazione RSC è ancora presente e questo da solo è sufficiente per attivare percorsi di codice vulnerabili e creare un significativo rischio RCE.
Il difetto deriva dal modo in cui il Protocollo di volo Reactl elabora determinati payload strutturati. Le versioni precedenti tentavano di percorrere i percorsi degli oggetti forniti nel payload senza verificare che la struttura fosse valida o prevista. Un aggressore poteva manipolare questo processo e infine raggiungere l'esecuzione del codice sul server. Non era richiesta alcuna autenticazione, configurazione speciale o logica specifica dell'app. Poiché il problema esiste nelle configurazioni predefinite, standard le distribuzioni sono esposte senza bisogno di condizioni insolite.
Lo sfruttamento si verifica quando gli aggressori inviano richieste HTTP POST dannose che abusano del "vm.runInThisContext” tramite le Azioni del Server. Mentre React non espone direttamente l'endpoint vulnerabile, Next.js lo fa, creando un vero e proprio vettore di attacco remoto.
Next.js accetta payload di Flight da qualsiasi richiesta, li elabora senza un'adeguata convalida e li passa al deserializzatore di React. Il sistema tratta questi input esterni come attendibili, consentendo agli aggressori di raggiungere esecuzione di codice remoto attraverso endpoint accessibili al pubblico con privilegi di processo Node.js completi sul server di destinazione.
La gravità aumenta significativamente perché le configurazioni predefinite rimangono vulnerabili a React2Shell (CVE-2025-55182) e il risultato rischio RCE. UN standard Applicazione Next.js che crei con create-next-app si espone senza richiedere alcun codice personalizzato o modifiche alla configurazione. I ricercatori di sicurezza confermano un'affidabilità di sfruttamento pari a quasi il 100% e segnalano che il 39% degli ambienti cloud esegue istanze vulnerabili, mentre il 44% di tutti gli ambienti esegue applicazioni Next.js esposte pubblicamente e interessate da React2Shell.
Comprendere l'esposizione a React2Shell
Le versioni vulnerabili si estendono su più release:
| Componente | Versioni interessate |
|---|---|
| React-server-dom-webpack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| pacco dom del server di reazione | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| react-server-dom-turbopack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
Poiché molti framework integrano il supporto RSC al loro interno, le applicazioni spesso ereditano il codice vulnerabile senza rendersene conto. Qualsiasi framework o bundler che distribuisca questi pacchetti può esporre l'applicazione a React2Shell (CVE-2025-55182) e al relativo rischio RCE. Tra questi:
- Next.js (router di app)
- Anteprima RSC di React Router
- Plug-in Vite RSC
- Plugin Parcel RSC
- SDK di Redwood
- Waku
- Expo
Next.js è particolarmente interessato perché utilizza endpoint correlati a RSC su HTTP per impostazione predefinita. Le versioni che iniziano con Build canary 14.3.0, insieme alla maggior parte 15.x e presto 16.x release, contengono l'implementazione vulnerabile. Chiunque esegua canary 14.3.0-canarino.77 o più tardi dovrebbe tornare al stabile 14.x branch finché non verrà pubblicata una versione canary corretta.
Versioni Next.js corrette includere:
| Componente | Versioni patchate |
|---|---|
| Next.js | 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 |
PoC pubblici e rilevamento affidabile
In seguito alla divulgazione della vulnerabilità, hanno iniziato a circolare numerose presunte proof-of-concept. Molte di esse erano inaccurate o basate su presupposti errati. L'autore originale della vulnerabilità, Lachlan Davidson, ha confermato pubblicamente... React2shell che i PoC di GitHub in circolazione non corrispondono all'exploit condiviso privatamente con i manutentori di React/Next.js e fornito dal suo proprio PoC.
Un problema importante dei primi tentativi pubblici è la loro incapacità di riconoscere che lo sfruttamento ha successo contro standard Distribuzioni Next.js senza la necessità di una logica applicativa specifica o di funzioni lato server.
I ricercatori di sicurezza di diverse organizzazioni hanno sottolineato che rilevare la vulnerabilità richiede più della semplice identificazione della presenza di RSC. Il team di Assetnote ha pubblicato un metodo di rilevamento affidabile e scanner in grado di confermare il problema senza utilizzare alcuna logica di exploit. Metasploit avrà presto un exploit disponibile anche per questa vulnerabilità.
L'approccio di rilevamento sfrutta il modo in cui React Server gestisce i riferimenti alle proprietà degli oggetti utilizzando i delimitatori di due punti all'interno di ReactFlightClientConfigBundlerWebpack.js/requireModule() funzione. Quando le versioni vulnerabili elaborano un payload multiparte appositamente strutturato che tenta di attraversare percorsi di oggetti annidati inesistenti, attivano risposte di errore prevedibili. Una richiesta diagnostica invia un pattern di riferimento come `$1:a:a` abbinato a un oggetto vuoto. Le implementazioni vulnerabili tentano di risolvere questo problema come accesso a proprietà annidate su un valore non definito, generando un'eccezione. Il server restituisce uno stato 500 con un pattern di digest di errore distintivo nel corpo della risposta.
export function requireModule<T>(metadata: ClientReference<T>): T {
let moduleExports = __webpack_require__(metadata[ID]);
if (isAsyncImport(metadata)) {
if (typeof moduleExports.then !== 'function') {
// This wasn't a promise after all.
} else if (moduleExports.status === 'fulfilled') {
// This Promise should've been instrumented by preloadModule.
moduleExports = moduleExports.value;
} else {
throw moduleExports.reason;
}
}
if (metadata[NAME] === '*') {
// This is a placeholder value that represents that the caller imported this
// as a CommonJS module as is.
return moduleExports;
}
if (metadata[NAME] === '') {
// This is a placeholder value that represents that the caller accessed the
// default property of this if it was an ESM interop module.
return moduleExports.__esModule ? moduleExports.default : moduleExports;
}
return moduleExports[metadata[NAME]];
}
Azioni immediate per le organizzazioni che affrontano React2Shell (CVE-2025-55182) e il rischio RCE
Esegui una scansione completa della tua base di codice e delle applicazioni distribuite Per individuare le versioni vulnerabili dei pacchetti. Prestare particolare attenzione alle dipendenze dirette dei pacchetti del server React, alle implementazioni RSC a livello di Framework (Next.js, Waku, Redwood, ecc.), alle applicazioni create con `create-next-app` o strumenti di scaffolding simili e alle applicazioni containerizzate che potrebbero contenere immagini di base obsolete.
Analisi della composizione del software (SCA) strumenti come Quello di Xygeni SCA può rilevare automaticamente le dipendenze interessate nell'intero inventario software.
Applicare subito la patch:
Aggiornamenti alle versioni patchate come React (19.0.1, 19.1.2, 19.2.1), Next.js (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7) e tutti i pacchetti framework che includono RSC. Questi aggiornamenti introducono una convalida rigorosa per la gestione del payload RSC e impediscono la dereferenziazione delle proprietà non sicura che ne consente lo sfruttamento.
Strumenti di bonifica automatizzati, come Funzione di auto-riparazione di Xygeni, può accelerare il processo su basi di codice di grandi dimensioni.
Implementare protezioni WAF temporanee:
Mentre le patch si propagano attraverso la distribuzione pipeline, attiva le regole del Web Application Firewall per una protezione immediata. I principali provider cloud hanno rilasciato set di regole di emergenza, Cloudflare: Protezione automatica per tutti i livelli quando il traffico React è proxy e anche AWS, Akamai, Fastly, Google Cloud avere regole difensive simili disponibili Abilitare immediatamente questi controlli per creare uno strato protettivo durante il periodo di transizione.
Monitora il traffico HTTP sospetto:
Configurare la registrazione e gli avvisi per gli indicatori di tentativi di sfruttamento: payload del protocollo RSC Flight malformati o inattesi, modelli insoliti di errori 500 sugli endpoint RSC, richieste POST con intestazioni sospette `Next-Action` o `Next-Router-State-Tree`, richieste ripetute ai percorsi `/_next/` con payload multiparte
Verifica la distinta base del tuo software:
Molti framework raggruppano le dipendenze RSC in modo trasparente, rendendole invisibili nelle revisioni delle dipendenze a livello superficiale. Esamina il tuo completo SBOM per garantire: che non rimangano dipendenze transitive sui pacchetti vulnerabili del server React e che gli aggiornamenti del framework non abbiano introdotto inavvertitamente implementazioni RSC più vecchie.
Pensieri di chiusura
React2Shell è tra le vulnerabilità più gravi dell'ecosistema JavaScript degli ultimi anni, non perché l'exploit sia complesso, ma perché RSC sfrutta in modo così approfondito gli strumenti odierni. Ora che le patch sono disponibili in tutto l'ecosistema, i team devono implementare gli aggiornamenti in produzione il più rapidamente possibile.
Se la tua applicazione utilizza le funzionalità del server di React, direttamente o indirettamente, devi trattare questa vulnerabilità come una correzione con la massima priorità.
