freeqaz/react2shellToolkit di exploit RCE per CVE-2025-55182 e CVE-2025-66478 in React Server Components. Include più varianti di exploit, script di rilevamento, un server di test vulnerabile e un'analisi tecnica approfondita della vulnerabilità di deserializzazione del protocollo Flight.
CVE-2025-55182 (React) e CVE-2025-66478 (Next.js)
Questo repository contiene codice exploit per test di sicurezza autorizzati e solo a scopo educativo.
Vedi anche: Molti ricercatori hanno pubblicato analisi di questa vulnerabilità. Controlla la sezione Riferimenti per prospettive aggiuntive, tecniche di sfruttamento e metodi di rilevamento.
Mercoledì 3 dicembre 2025, è stata divulgata pubblicamente una vulnerabilità critica di Remote Code Execution in React Server Components. Il bug, soprannominato 'React2Shell', consente a un attaccante non autenticato di eseguire codice arbitrario su qualsiasi server che esegue versioni vulnerabili di React RSC o Next.js App Router inviando una singola richiesta HTTP.
Dato quanto Next.js sia diventato pervasivo - alimenta una porzione significativa del web moderno - l'impatto di questa vulnerabilità è grave. Qualsiasi applicazione Next.js che utilizza App Router (il predefinito per i nuovi progetti da Next.js 13) con RSC abilitato è vulnerabile. Nessuna configurazione speciale. Nessun endpoint specifico. Solo una richiesta POST a qualsiasi route.
La vulnerabilità risiede nel protocollo 'Flight' di React, il formato di serializzazione utilizzato per passare dati tra server e client in React Server Components. Un controllo hasOwnProperty mancante durante la deserializzazione consente la traversata della catena dei prototipi, raggiungendo infine il costruttore di Function di JavaScript per eseguire codice controllato dall'attaccante.
Il difetto esiste nei pacchetti React , e . Next.js, come consumatore dominante di RSC, eredita la vulnerabilità attraverso il suo App Router.
react-server-dom-webpackreact-server-dom-turbopackreact-server-dom-parcelMolti servizi sono potenzialmente vulnerabili. Next.js è uno dei framework React più popolari, utilizzato da aziende di tutte le dimensioni - dalle startup alle grandi imprese. App Router con React Server Components è l'architettura predefinita per i nuovi progetti Next.js dalla versione 13, il che significa che la maggior parte delle distribuzioni moderne di Next.js è interessata.
Qualsiasi applicazione che utilizza:
react-server-dom-* vulnerabili (19.0.0 - 19.2.0)Ciò include distribuzioni in produzione su Vercel, AWS, infrastrutture self-hosted e ovunque siano eseguite applicazioni Next.js App Router.
Non interessati:
process.mainModule disponibile)| Pacchetto | Vulnerabile | Corretto |
|---|---|---|
react-server-dom-webpack | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1+ |
react-server-dom-turbopack | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1+ |
react-server-dom-parcel | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1+ |
| Linea di versione | Vulnerabile | Corretto |
|---|---|---|
| 15.0.x | < 15.0.5 | 15.0.5+ |
| 15.1.x | < 15.1.9 | 15.1.9+ |
| 15.2.x | < 15.2.6 | 15.2.6+ |
| 15.3.x | < 15.3.6 | 15.3.6+ |
| 15.4.x | < 15.4.8 | 15.4.8+ |
| 15.5.x | < 15.5.7 | 15.5.7+ |
| 16.0.x | < 16.0.7 | 16.0.7+ |
Aggiorna immediatamente. Non ci sono soluzioni alternative.
Per applicazioni Next.js:
npm install next@latest
# or
pnpm update next
Per uso diretto di React RSC:
npm install react-server-dom-webpack@latest
Verifica le tue versioni installate:
npm ls next react-server-dom-webpack react-server-dom-turbopack
Sono stati scoperti molteplici vettori d'attacco per questa vulnerabilità. Il più comune - e quello che funziona senza prerequisiti - utilizza il prototype pollution attraverso il sistema di riferimento del protocollo Flight di React.
L'exploit invia una richiesta POST multipart costruita ad arte con un header Next-Action. Il payload abusa del sistema di riferimento per:
$1:__proto__:thenFunction di JavaScriptPOST / HTTP/1.1
Host: target.com
Content-Type: multipart/form-data; boundary=----Boundary
Next-Action: x
------Boundary
Content-Disposition: form-data; name="0"
{"then":"$1:__proto__:then","status":"resolved_model","value":"{...}","_response":{...}}
------Boundary
Content-Disposition: form-data; name="1"
"$@0"
------Boundary--
Il codice viene eseguito durante la deserializzazione, prima che avvenga qualsiasi validazione dell'ID azione. Ciò significa che qualsiasi valore dell'header Next-Action attiva il percorso di codice vulnerabile - nessun ID azione valido è richiesto.
Altri vettori d'attacco esistono, inclusi i riferimenti a funzioni
$Fe gadget di moduli diretti. Questi tipicamente richiedono un ID azione valido. Vedi Vettori d'attacco alternativi per dettagli.
Il protocollo Flight di React risolve riferimenti come $1:path:to:value dividendo sui due punti e attraversando l'oggetto:
// ReactFlightReplyServer.js - getOutlinedModel()
for (let i = 1; i < path.length; i++) {
value = value[path[i]]; // No hasOwnProperty check!
}
L'ironia: All'inizio di questo stesso file, riga 35:
import hasOwnProperty from 'shared/hasOwnProperty';La guardia era stata importata. Era disponibile. Semplicemente non è stata usata nel ciclo in cui contava di più.
Questa singola verifica mancante consente a $1:__proto__:then di attraversare da un oggetto chunk, lungo la catena dei prototipi, fino a Chunk.prototype.then - una funzione che elabora oggetti simili a Promise. Creando un falso chunk con le proprietà giuste, controlliamo quale codice viene eseguito.
Clona il server di test vulnerabile:
git clone https://github.com/freeqaz/react2shell
cd react2shell/vulnerable-next-server
pnpm install
pnpm dev
In un altro terminale:
./detect.sh http://localhost:3443
Un server vulnerabile restituisce HTTP 500 con E{"digest" nel corpo della risposta. Per dimostrare RCE:
./exploit-redirect.sh http://localhost:3443 "id"
L'output del comando appare nella risposta. Per esplorazione interattiva:
./shell.sh http://localhost:3443
La directory vulnerable-next-server/ contiene un'applicazione Next.js 16.0.6 + React 19.2.0 preconfigurata per test locali sicuri. Viene eseguita sulla porta 3443 per impostazione predefinita. Questa è una configurazione minima di App Router che dimostra che le configurazioni predefinite sono vulnerabili.
Abbiamo sviluppato molteplici varianti di exploit per gestire diversi scenari:
| Script | HTTP | Output | Produzione | Note |
|---|---|---|---|---|
exploit-redirect.sh | 303 | x-action-redirect header | Sì | Raccomandato. Nessun prerequisito. |
exploit-throw.sh | 500 | Corpo della risposta di errore | No | Solo modalità sviluppo (errori sanitizzati in produzione). |
exploit-blind.sh | 200 | Solo lato server | Sì | Fire-and-forget. Usa per esfil OOB. |
exploit-urlencoded.sh | 303 | x-action-redirect header | Sì | Firma WAF diversa. Richiede ID azione. |
exploit-reflect.sh | 200 | Corpo della risposta | Sì | Il più furtivo. Richiede ID azione. |
Nota sulla produzione: React rimuove i dettagli degli errori nelle build di produzione, rompendo il metodo
throw. Soloexploit-redirect.shcattura in modo affidabile l'output dei comandi in produzione senza prerequisiti. L'URL di reindirizzamento è memorizzato nella proprietàdigestdell'errore (metadati), che non viene sanitizzata - a differenza dimessageche diventa solo{digest: "..."}.
Script Utilità:
detect.sh - Sonda di vulnerabilità non distruttiva (nessuna esecuzione di codice)enumerate-actions.sh - Scopre ID di Server Action validi dall'HTML di destinazioneexfil-file.sh - Esfiltrazione di file a blocchi (gestisce automaticamente file grandi)shell.sh - Pseudo-shell interattiva tramite RCEIl metodo redirect è raccomandato perché funziona in produzione, non richiede prerequisiti e restituisce direttamente l'output dei comandi. Funziona lanciando un errore NEXT_REDIRECT appositamente costruito - l'output è codificato in base64 nell'URL di reindirizzamento e restituito nell'header x-action-redirect.
Per l'utilizzo dettagliato di ogni script, vedi USAGE.md.
./detect.sh https://target.com
Questo invia una sonda minima che attiva il percorso di codice vulnerabile senza eseguire codice arbitrario.
Risposta del server vulnerabile:
text/x-componentE{"digest"Server corretto o non-RSC: Restituisce 404, formato errore diverso o nessuna risposta del protocollo Flight.
curl -s -o /dev/null -w "%{http_code}" -X POST https://target.com \
-H "Next-Action: x" \
-H "Content-Type: multipart/form-data; boundary=----Boundary" \
--data-binary $'------Boundary\r\nContent-Disposition: form-data; name="0"\r\n\r\n["$1:a:a"]\r\n------Boundary\r\nContent-Disposition: form-data; name="1"\r\n\r\n{}\r\n------Boundary--'
Questa sonda fa riferimento a una proprietà inesistente su un oggetto vuoto. I server vulnerabili si bloccano tentando di accedere a {}.a.a, restituendo 500. I server corretti hanno una guardia hasOwnProperty che impedisce il crash.
Cerca questi indicatori:
<script> contenenti dati del protocollo Flight (0:, 1:, ecc.)x-nextjs-cache o x-nextjs-matched-path/_next/$ACTION_ID_ nei campi modulo nascostiIl seguente diagramma illustra come una singola richiesta HTTP raggiunge l'esecuzione di codice remoto:
sequenceDiagram
participant A as Attacker
participant N as Next.js
participant F as Flight Parser
participant JS as JS Engine
A->>N: POST with Next-Action header + malicious payload
N->>F: Parse multipart form data
F->>JS: await getRoot - returns chunk as thenable
rect rgb(80, 20, 20)
Note over F,JS: VULNERABILITY - No hasOwnProperty check
JS->>F: chunk.then parses $1:__proto__:then
F-->>F: Traverses to Chunk.prototype.then
end
F->>JS: resolve(attackerObject)
Note over JS: JS Promise spec: resolve(thenable)<br/>calls thenable.then()
JS->>F: fakeChunk.then() with attacker's _response
rect rgb(80, 20, 20)
Note over F,JS: EXPLOITATION - Attacker controls _response
F->>F: $B0 → _formData.get(_prefix + "0")
Note over F: _formData.get = Function constructor<br/>_prefix = malicious code string
F->>JS: Function(code) invoked as thenable
end
Note over JS: RCE - execSync() runs
rect rgb(20, 60, 20)
Note over A,JS: OUTPUT EXFILTRATION (redirect method)
JS-->>F: throw NEXT_REDIRECT with base64(output)
F-->>N: Error propagates up
N-->>A: HTTP 303 + x-action-redirect header
endReact Server Components utilizza un formato di serializzazione personalizzato chiamato 'Flight' per trasmettere alberi di componenti dal server al client. Utilizza codici prefisso per diversi tipi di valore:
$1, $2, ... - Riferimenti ad altri chunk tramite ID$@0 - Riferimento all'oggetto chunk grezzo (restituisce il chunk stesso, non il suo valore)$B0 - Riferimento blob (attiva _formData.get(_prefix + id))$1:path:to:prop - Attraversa un percorso sul valore di un chunk referenziatoLa vulnerabilità sfrutta la combinazione di $@ (riferimento grezzo) e percorsi delimitati da due punti per accedere a __proto__.
Fase 1: Elaborazione della Richiesta
Next-Action attiva la gestione delle azioni RSCawait getRoot(response) restituisce il chunk 0 come thenableFase 2: Attraversamento del Prototipo
then - la specifica Promise JS chiama thenable.then(resolve, reject)$1:__proto__:then risolve in Chunk.prototype.thenthen, status: "resolved_model" e _responseFase 3: Esecuzione del Codice
resolve(ourObject) attiva un'altra chiamata then() (specifica thenable JS)Chunk.prototype.then viene eseguito utilizzando il nostro oggetto _response controllato$B0 attiva _formData.get(_prefix + "0") - entrambi controllati dall'attaccanteFunction costruita chiamata come thenable → RCEFase 4: Esfiltrazione dell'Output (opzionale, metodo redirect)
NEXT_REDIRECT con output del comando codificato in base64x-action-redirect prima della validazione dell'URLLa Function costruita viene chiamata come thenable: fn(resolve, reject). Il modo in cui gestiamo questo determina se riceviamo l'output:
| Strategia | Suffisso del Payload | Come Funziona |
|---|---|---|
| Cieco | execSync('CMD');0 | Esegue ma non risolve mai - la connessione si blocca, nessun output |
| Lancia | throw execSync('CMD').toString() | Rifiuta la Promise, output nel corpo dell'errore (solo modalità sviluppo) |
| Reindirizza | throw {digest:'NEXT_REDIRECT;...;'+b64(output)} | Abusa della gestione del reindirizzamento di Next.js, output nell'header |
| Rifletti | arguments[0](https://github.com/freeqaz/react2shell/blob/master/%5BexecSync%28%27CMD%27).toString()]) | Risolve la Promise con output come argomento dell'azione (richiede ID azione valido) |
Raccomandato: Reindirizza. Funziona in produzione, nessun prerequisito, output nell'header x-action-redirect.
L'approccio cieco si blocca perché la Promise non si stabilizza mai - await blocca all'infinito. Questo è utile per scenari fire-and-forget (reverse shell, esfil fuori banda tramite curl).
La vulnerabilità principale è stata sfruttata attraverso tre classi di attacco distinte. Questo repository utilizza il primo approccio; altri PoC dimostrano le alternative:
| Classe di Attacco | Meccanismo | ID Azione Richiesto | Esempio PoC |
|---|---|---|---|
| Prototype Pollution | Attraversamento $1:__proto__:then a Chunk.prototype | No | react2shell, lachlan2k, joe-desimone |
| $F Function Reference | $F1 + action#constructor per raggiungere Function | Sì | shellinteractive |
| Module Gadget | Sintassi module#export (es. child_process#execSync) | Varia | ricerca ejpir |
Perché il prototype pollution non richiede un ID azione: L'analisi del modulo multipart alimenta i chunk al deserializzatore Flight immediatamente. La RCE avviene in getOutlinedModel() durante la risoluzione del riferimento al chunk - prima che Next.js convalidi l'ID azione. Le richieste con codifica URL convalidano prima l'ID azione (percorso di codice diverso in action-handler.ts:768).
Perché il riferimento $F richiede un ID azione: Il riferimento $F attiva loadServerReference(), che esegue una ricerca nel manifest. Se l'azione non esiste, la richiesta fallisce prima dell'esecuzione del codice.
Per un'analisi dettagliata di tutte le implementazioni PoC e i loro compromessi, vedi external-pocs/COMPARISON.md.
React rimuove i dettagli degli errori nelle build di produzione. Questo influisce sull'esfiltrazione basata su throw:
Sviluppo:
{"digest":"...","name":"Error","message":"uid=501(free)...","stack":[...]}
Produzione:
{"digest":"..."}
Il metodo redirect bypassa questo perché l'URL di reindirizzamento è memorizzato nella proprietà digest, non in message. L'header viene impostato incondizionatamente prima della validazione dell'URL, quindi anche URL non validi ottengono l'header impostato.
L'intuizione chiave dello sfruttamento - usare riferimenti chunk grezzi $@ per creare un falso chunk autoreferenziale - è attribuita a maple3142. La metodologia di rilevamento qui citata proviene da Searchlight Cyber / Assetnote.
Divulgazioni Ufficiali:
Ricerca della Comunità:
| Autore | Contributo | Percorso d'Attacco | Caratteristiche Notevoli |
|---|---|---|---|
| lachlan2k | Scopritore originale | Prototype pollution | Chaining Array.map, struttura a 5 chunk, supporto Waku |
| ejpir | Ricerca gadget | Tutti i percorsi | Catalogo gadget modulo, attacchi di persistenza, percorso data URI |
| joe-desimone | Strumentazione Python | Prototype pollution | Helper reverse shell, esfil callback, rilevamento timeout |
| labubusDest / MrR0b0t19 | Shell interattiva | Riferimento funzione $F | REPL Python, upload/download file, suite di test integrata |
| Searchlight Cyber | Metodi di rilevamento | — | Metodologia di rilevamento ad alta fedeltà, firme WAF |
Per un confronto dettagliato di tutte le implementazioni PoC, vedi external-pocs/COMPARISON.md.
Contesto:
Il codice è concesso in licenza sotto MIT License. La documentazione (file *.md) è concessa in licenza sotto CC-BY-SA 4.0.