ritinify/cve-2025-29927-pocProof-of-concept exploit per CVE-2025-29927, un bypass dell'autorizzazione middleware di Next.js. Include un laboratorio target vulnerabile e uno script Python per verificare il bypass inviando header x-middleware-subrequest appositamente costruiti.
Un piccolo progetto GitHub per verificare CVE-2025-29927 (Bypass dell'autorizzazione del middleware Next.js) in un laboratorio di autorizzazione locale (VMware: macchina target Ubuntu + macchina attaccante Kali).
⚠️ Disclaimer: questo progetto è destinato esclusivamente a scopi educativi, CTF e ambienti di laboratorio di tua proprietà/espressamente autorizzati. È severamente vietato l'uso su sistemi non autorizzati. L'utente è l'unico responsabile delle conseguenze derivanti da un uso improprio di questo progetto.
| Elemento | Contenuto |
|---|---|
| CVE | CVE-2025-29927 |
| Data di divulgazione | 2025-03-25 (bollettino di sicurezza ufficiale Next.js) |
| Componente interessato | Vercel Next.js (framework full-stack Node.js) |
| Tipo di vulnerabilità | Bypass dell'autorizzazione / Autorizzazione impropria (CWE-863) |
| Versioni interessate | < 12.3.5、< 13.5.9、< 14.2.25、< 15.2.3 |
| Versioni corrette | 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 e successive |
| Livello di gravità | Critical / Alto (il punteggio specifico fa riferimento alla pagina NVD) |
Dopo la divulgazione della vulnerabilità, numerosi pannelli di amministrazione, callback di pagamento e API interne in ambienti di produzione sono stati bypassati. Sia Metasploit che ProjectDiscovery Nuclei hanno incluso moduli di rilevamento; si tratta di una delle vulnerabilità di "bypass dell'autorizzazione a livello di framework" più rappresentative del 2025.
Next.js consente di scrivere la "logica di autenticazione" nel middleware, ad esempio:
export function middleware(request) {
if (!isLogin(request)) return NextResponse.redirect("/login"); // Non autenticato → blocca
return NextResponse.next();
}
Il problema è che Next.js internamente si affida a un'intestazione di richiesta falsificabile dal client per determinare se "questa richiesta ha già eseguito il middleware":
x-middleware-subrequest: middleware
Nelle versioni interessate, se una richiesta esterna trasporta questa intestazione interna, Next.js presume erroneamente che il middleware sia già stato eseguito, quindi l'intero middleware di autenticazione viene saltato. L'attaccante non ha bisogno di alcun account: basta inviare questa intestazione per accedere direttamente con stato 200 a rotte protette come /admin — poiché la pagina stessa di solito si fida del middleware e non esegue una seconda verifica, il controllo di autorizzazione viene meno (errore di confine di fiducia).
💡 Il valore più comune nell'exploit pubblico è la forma con il percorso del middleware ripetuto e concatenato, ad esempio
middleware:middleware:middleware:middleware:middleware; un singolomiddlewarenon funziona in alcune versioni/strutture di directory (verificato in questo laboratorio con la 14.2.24). Questo PoC esegue il polling di diversi valori candidati; se uno qualsiasi corrisponde, il bypass ha successo.
CVE-2025-29927-PoC/
├── README.md # Questo documento (descrizione vulnerabilità + tutorial laboratorio VMware)
├── LICENSE # MIT
├── .gitignore
├── exploit.py # ★ PoC di verifica Python3 solo libreria standard (eseguibile su Kali/qualsiasi macchina)
├── target/ # ★ Laboratorio vulnerabile autocostruito (da copiare sulla macchina target Ubuntu)
│ ├── package.json # Blocca [email protected] (versione vulnerabile)
│ ├── middleware.js # Simula il "middleware di autenticazione" di una produzione reale
│ ├── pages/
│ │ ├── index.js # Home page
│ │ ├── login.js # Pagina di login (dimostra il reindirizzamento qui)
│ │ └── admin.js # ★ Pannello di amministrazione protetto, legge flag.txt lato server
│ ├── flag.txt # Flag del laboratorio: FLAG{...}
│ ├── setup.sh # Installazione一键 Node 20 + npm install + build sulla macchina target
│ └── start.sh # Ascolto in modalità produzione su 0.0.0.0:3000
└── tests/
└── mock_target.py # Target simulato senza Node (solo per auto-test di sviluppo)
┌───────────────────────────────────────────────────────────┐
│ VMware Workstation Pro 17 (host: Windows) │
│ Rete: NAT (VMnet8 predefinita), due VM stessa sottorete, ping reciproco │
│ │
│ ┌──────────────────┐ ┌─────────────────────┐ │
│ │ Target Ubuntu 24.04 │ │ Attaccante Kali Linux │ │
│ │ │ http │ │ │
│ │ Node 20 + Next │◄───────│ python3 exploit.py │ │
│ │ 14.2.24 :3000 │ GET │ │ │
│ └──────────────────┘ └─────────────────────┘ │
│ IP: <TARGET_IP> IP: <ATTACKER_IP> │
└───────────────────────────────────────────────────────────┘
| Scopo | Immagine/Software | Versione consigliata |
|---|---|---|
| Software VM | VMware Workstation Pro 17 (gratuito per uso personale) | 17.x |
| Immagine target | ISO Ubuntu Server LTS | 24.04.x |
| Macchina attaccante | Kali Linux (immagine VMware ufficiale preimpostata o installazione ISO) | 2025.x |
| (Opzionale) | Host con almeno 8 GB di RAM e 50 GB di disco | — |
Tutti i passaggi seguenti vengono eseguiti sulla macchina target Ubuntu.
# Metodo A: push del progetto sul proprio GitHub e poi clone (consigliato, usalo se poi farai push su GitHub)
git clone https://github.com/<il-tuo-username>/CVE-2025-29927-PoC.git
cd CVE-2025-29927-PoC
# Metodo B: copia dall'host con scp
# scp -r CVE-2025-29927-PoC ubuntu@<TARGET_IP>:~/
cd CVE-2025-29927-PoC/target
sudo bash setup.sh # Installa Node 20(LTS) + npm install + next build