Analisi Tecnica di CVE-2025-55182: Il Mio Percorso di Ricerca

⚠️ Avvertenza Importante

Questo documento descrive il mio processo di ricerca personale su CVE-2025-55182, inclusi risultati confermati ed esperimenti che ho condotto. Rappresenta un resoconto onesto della mia indagine, incluse ipotesi iniziali errate e la svolta finale.

Riepilogo Esecutivo

Dopo un'indagine approfondita su CVE-2025-55182 (CVSS 10.0), la mia conclusione iniziale era che l'RCE automatica non fosse stata dimostrata pubblicamente e che lo sfruttamento richiedesse gadget specifici dell'applicazione. Questa conclusione era errata.

Il 5 dicembre 2025, dopo aver ricevuto ulteriori approfondimenti da un altro ricercatore indipendente su X (@maple3142), ho riprodotto con successo RCE completa non autenticata su Next.js vanilla senza richiedere vulnerabilità di codice specifiche dell'applicazione.

Metodologia di Ricerca

Fase 1: Analisi della Patch (Ipotesi Iniziale Errata)

Il mio focus iniziale era sul primo cambiamento nella patch di React 19.0.1:

Vulnerabile (19.0.0):

return fn.bind.apply(fn, [null].concat(_ref));

Corretto (19.0.1):

if (Array.isArray(promiseValue)) {
  promiseValue = promiseValue.slice(0);
} else {
  promiseValue = [];
}

Ho ipotizzato che il percorso dell'attacco fosse tramite fn.bind.apply() con oggetti malevoli invece di array. Sono riuscito a dimostrare l'iniezione di argomenti nelle Azioni del Server utilizzando $ACTION_REF_ con bound controllato dall'attaccante:

curl -X POST http://localhost:9000/ \
  -F '$ACTION_REF_0=' \
  -F '$ACTION_0:0={"id":"<ACTION_ID>","bound":["; id #","/etc/passwd"]}'

Risultato: Gli argomenti sono stati iniettati con successo nell'Azione del Server. Tuttavia, questo porta a RCE solo se la funzione di destinazione utilizza tali argomenti in modo non sicuro.

Fase 2: Comportamento Non Sicuro Osservato nella Patch

Uno sguardo più approfondito alla patch ha rivelato un altro importante cambiamento in getOutlinedModel():

Vulnerabile:

for (key = 1; key < reference.length; key++)
  parentObject = parentObject[reference[key]];

Corretto:

if (hasOwnProperty.call(value, name)) {
  value = value[name];
}

Questo comportamento vulnerabile consentiva l'attraversamento della catena dei prototipi utilizzando riferimenti come:

$1:__proto__:constructor:constructor

Fase 3: Esperimento con Thenable e Function.constructor (Vicolo Cieco)

Durante la ricerca, ho testato un oggetto thenable contenente una proprietà .then:

{"then": "$1:__proto__:constructor:constructor"}

Quando JavaScript elabora questo tramite await:

1. JavaScript vede una proprietà .then e tratta l'oggetto come una Promise
2. Chiama obj.then(resolve, reject)
3. Se then risolve a Function.constructor, JavaScript tenta di eseguire Function(resolve, reject)

Risultato osservato:

SyntaxError: Unexpected token 'function'
    at Object.Function [as then] (<anonymous>)

Fase 4: La Limitazione del Binding degli Argomenti (Il Muro)

Quando Function.constructor viene invocato come:

Function(resolve, reject)
// resolve.toString() = "function () { [native code] }"
// Function tenta di interpretare questo come codice → SyntaxError

Gli argomenti resolve e reject sono sempre le funzioni native di Promise. Function tenta di interpretare il primo argomento come codice sorgente, che è JavaScript non valido.

È qui che la mia ricerca si è fermata. Ho concluso che controllare gli argomenti di Function.constructor era impossibile senza un gadget specifico dell'applicazione.

Fase 5: La Svolta — Deserializzazione Blob (5 Dicembre 2025)

Dopo aver pubblicato i miei risultati iniziali, un altro ricercatore indipendente mi ha indicato un pezzo critico che mi era sfuggito: il sink di deserializzazione $B (Blob).

Il Pezzo Mancante

Nel codice compilato del server React Flight (non visibile nelle fonti TypeScript), esiste:

case "B":
  return response._formData.get(response._prefix + id);

Posizione:

• Package: [email protected]
• File: cjs/react-server-dom-webpack-server.node.unbundled.development.js
• Anche in: [email protected]/dist/compiled/react-server-dom-webpack/

Questo codice permette a React di chiamare response._formData.get() con valori derivati da input controllati dall'attaccante, senza validazione.

Perché Questo Cambia Tutto

Combinando:

1. Attraversamento del prototipo ($1:__proto__:then → Chunk.prototype.then)
2. Un oggetto _response avvelenato con:
   • _formData.get impostato su Function.constructor
   • _prefix impostato su codice JavaScript arbitrario
3. Un modello interno contenente un riferimento $B

Il gestore case "B": esegue:

Function.constructor("<codice attaccante>" + id)

Questo bypassa completamente la limitazione del binding degli argomenti.

PoC Pubbliche: Analisi

Le PoC GitHub popolari che rivendicano RCE utilizzano ID di azione come:

• "child_process#execSync"
• "vm#runInThisContext"

Queste sono false. Next.js accetta solo ID di azione definiti dall'applicazione. ID non validi producono:

TypeError: Cannot read properties of undefined (reading 'workers')

Tuttavia, il vero exploit non richiede ID di azione falsi. Qualsiasi ID di Azione del Server valido funziona.

Verifica e Impatto

Ho testato questa catena di sfruttamento su un'applicazione minima Next.js 15.0.3 + React 19.0.0 con solo:

async function myAction(data) {
  "use server";
  console.log("Server Action called with:", data);
  return { success: true, received: data };
}

Risultato: RCE completa confermata. L'applicazione non conteneva codice non sicuro, nessun eval, nessun execSync, nessun gadget.

Valutazione dell'Impatto

Scoperta Critica: Stato della Patch

Al 5 dicembre 2025, il sink $B esiste ancora in Next.js 15.0.5 (la versione presumibilmente corretta).

Verifica:

$ npm pack [email protected]
$ tar -xzf next-15.0.5.tgz
$ grep -A5 'case "B":' package/dist/compiled/react-server-dom-webpack/cjs/react-server-dom-webpack-server.node.development.js

Risultato:

case "B":
  return response._formData.get(response._prefix + obj);

Il codice è identico alla versione vulnerabile.

Nota sulla Divulgazione Responsabile

A causa della scoperta che la vulnerabilità potrebbe non essere completamente corretta nelle versioni dichiarate "fisse", sto trattenendo il payload proof-of-concept completo in attesa di verifica con i team di sicurezza di Vercel e Meta.

I dettagli tecnici forniti in questo documento sono sufficienti per comprendere il meccanismo della vulnerabilità ma intenzionalmente incompleti per prevenire uno sfruttamento immediato.

Conclusioni Aggiornate

Cosa Ho Trovato (Fasi 1-4)

Cosa Mi è Sfuggito Inizialmente

Valutazione Finale

CVE-2025-55182 è sfruttabile per RCE completa non autenticata su applicazioni Next.js vanilla.

• ✅ Nessun gadget specifico dell'applicazione richiesto
• ✅ Funziona con un singolo POST HTTP
• ✅ Il "gadget" è integrato nella logica di deserializzazione di React
• ⚠️ Potrebbe non essere completamente corretta nelle versioni dichiarate fisse

Cronologia

• 3 dicembre 2025: Analisi dell'attraversamento del prototipo e approccio thenable (vicolo cieco)
• 4 dicembre 2025: Ricevuta l'intuizione sulla deserializzazione $B da un ricercatore indipendente
• 5 dicembre 2025: Riproduzione completa dell'RCE confermata
• 5 dicembre 2025: Scoperto che la vulnerabilità potrebbe persistere nelle versioni "corrette"
• 5 dicembre 2025: Questo rapporto pubblicato (dettagli PoC trattenuti)

Raccomandazioni

1. Aggiornare immediatamente alle ultime versioni di React e Next.js
2. Verificare la patch testando se la deserializzazione $B accetta ancora oggetti _response arbitrari
3. Monitorare i tentativi di sfruttamento - cercare:
   • Intestazioni Next-Action insolite
   • Payload multipart complessi con pattern $@, __proto__, $B
4. Considerare regole WAF per bloccare pattern sospetti nelle richieste di Azioni del Server
5. Contattare i team di sicurezza se si eseguono versioni affette in produzione

Riconoscimenti

• L'intuizione cruciale sulla deserializzazione $B è stata fornita da un ricercatore su X (@maple3142)
• I team di sicurezza di React e Next.js per il loro lavoro sulle patch (verifica in corso)
• La comunità di ricerca sulla sicurezza per l'indagine collaborativa

Lezioni Apprese

1. Esaminare il codice compilato, non solo le fonti - Vulnerabilità critiche possono nascondersi nell'output bundle
2. Rivedere le ipotesi quando emergono nuove informazioni
3. La ricerca collaborativa è essenziale per vulnerabilità complesse
4. Documentare il percorso - I vicoli ciechi sono preziosi per comprendere il quadro completo
5. La divulgazione responsabile ha la precedenza sul riconoscimento pubblico

Ultimo aggiornamento: 5 dicembre 2025