iteride/cve-2025-29927Analisi approfondita e PoC per CVE-2025-29927, un bypass dell'autorizzazione middleware di Next.js tramite l'header x-middleware-subrequest. Include template Nuclei e uno script di scansione di massa per i test.
Questo documento presenta un'analisi della vulnerabilità CVE-2025-29927, che riguarda il meccanismo Middleware nel framework Next.js.
Next.js è un popolare framework open-source di Vercel per lo sviluppo di applicazioni basate su React. Supporta il rendering lato server, la generazione statica e un flessibile sistema di middleware, utilizzato per routing, reindirizzamenti, header di sicurezza e controllo degli accessi.
Nel marzo 2025 è stata identificata una vulnerabilità critica CVE-2025-29927, legata alla gestione dell'header interno delle sotto-richieste.
Il problema consiste nella possibilità di aggirare i controlli di autorizzazione nelle applicazioni in cui il controllo degli accessi è implementato proprio nel middleware, inserendo un valore speciale nell'header HTTP x-middleware-subrequest. Se la sicurezza è affidata solo al middleware, un attaccante può ottenere accesso a rotte o dati protetti.
Versioni di Next.js interessate e correzioni (secondo fonti pubbliche e materiali ufficiali):
Le correzioni sono disponibili nelle release 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.
Next.js è ampiamente utilizzato in produzione; una vulnerabilità che colpisce il layer middleware (spesso usato per autenticazione/autorizzazione e policy di sicurezza) comporta un elevato rischio pratico.
Analizzare passo dopo passo la vulnerabilità e documentare l'intero ciclo di ricerca:
Raccolta e strutturazione dei materiali.
Sistematizzare le fonti pubbliche relative a CVE-2025-29927; esporre la natura del difetto, le condizioni di attivazione e le versioni/patch confermati.
Determinazione delle CPE e delle condizioni di configurazione.
Fornire un elenco di CPE/versioni e descrivere le configurazioni in cui la vulnerabilità è riproducibile (ad esempio, deployment self-hosted e autorizzazione a livello di middleware).
Dimostrazione sicura.
Preparare una demo riproducibile in un ambiente di test (senza azioni distruttive), che confermi l'aggiramento del middleware nelle versioni vulnerabili.
Metodologie di verifica su larga scala.
Descrivere e implementare tre approcci sicuri:
Causa principale. In Next.js, l'header interno x-middleware-subrequest viene utilizzato per tracciare le sotto-richieste interne e prevenire la ricorsione nel middleware. Nei rami vulnerabili, i client esterni possono inserire questo header con un valore «atteso» e il runtime salta l'esecuzione del middleware, inoltrando la richiesta direttamente all'handler della rotta.
Ruolo dell'header. L'header x-middleware-subrequest era stato originariamente concepito come indicatore interno del fatto che la richiesta HTTP corrente fosse stata avviata dal framework stesso come sotto-richiesta intermedia, e non arrivata direttamente dall'utente.
Serve per il corretto funzionamento dei meccanismi interni di Next.js: oltre al routing, questo flag aiuta a evitare la ricorsione infinita, «marcando» ogni layer intermedio invocato.
Ma è proprio questa logica a creare un involontario buco nella protezione: un client che aggiunge autonomamente tale header può indurre il sistema a trattare la propria richiesta come interna e quindi aggirare i controlli di autorizzazione.
Evoluzione della logica.
Le attuali registrazioni NVD indicano il prodotto Vercel Next.js con software target node.js. Per i rami vulnerabili si applicano le seguenti configurazioni (gli intervalli di versione sono definiti a livello di configurazioni CPE in NVD):
| CPE URI | Intervallo di versioni vulnerabili |
|---|---|
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 11.1.4 ≤ v < 12.3.5 |
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 13.0.0 ≤ v < 13.5.9 |
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 14.0.0 ≤ v < 14.2.25 |
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:* | 15.0.0 ≤ v < 15.2.3 |
Nota: nella descrizione della CVE viene inoltre indicato che, in generale, «dalla 11.1.4 fino a 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3» la vulnerabilità è riproducibile al verificarsi delle condizioni seguenti.
next start, build con output: 'standalone') o qualsiasi ambiente in cui il middleware viene eseguito sulle richieste in ingresso senza filtraggio perimetrale degli header interni.x-middleware-subrequest (ad esempio, regole WAF).x-middleware-subrequestPer evitare una ricorsione infinita del codice intermedio, il runtime genera e legge un header interno:
: — si ottiene un array di «sotto-richieste».NextResponse.next()),x-middleware-subrequest-id), associato alla sessione corrente del processo; se non corrisponde, l'x-middleware-subrequest in ingresso viene cancellato lato server.Un attaccante invia una richiesta HTTP all'applicazione Next.js target, aggiungendo l'header interno x-middleware-subrequest.
Nel valore viene indicato il percorso del file middleware, ad esempio pages/_middleware, middleware o src/middleware.
Il valore necessario dipende dalla versione di Next.js utilizzata e dalla struttura del progetto.
Quando tale richiesta raggiunge l'applicazione, la logica interna del framework la considera una sotto-richiesta interna e presuppone che il layer intermedio sia già stato eseguito.
Di conseguenza, i controlli di autenticazione e autorizzazione che normalmente avvengono nel middleware vengono di fatto saltati.