ritinify/cve-2025-29927-pocPreuve de concept d'exploitation pour CVE-2025-29927, un contournement d'autorisation du middleware Next.js. Inclut un laboratoire cible vulnérable et un script Python pour vérifier le contournement en envoyant des en-têtes x-middleware-subrequest spécialement conçus.
Un petit projet GitHub pour valider CVE-2025-29927 (contournement de l'autorisation du middleware Next.js) dans un environnement de laboratoire local (VMware : machine cible Ubuntu + machine d'attaque Kali).
⚠️ Avertissement : Ce projet est uniquement destiné à l'éducation en sécurité, aux CTF et aux environnements de laboratoire que vous possédez ou pour lesquels vous disposez d'une autorisation explicite. Toute utilisation sur des systèmes non autorisés est strictement interdite. Les conséquences d'une mauvaise utilisation de ce projet relèvent de la seule responsabilité de l'utilisateur.
| Élément | Contenu |
|---|---|
| CVE | CVE-2025-29927 |
| Date de divulgation | 2025-03-25 (bulletin de sécurité officiel Next.js) |
| Composant affecté | Vercel Next.js (framework full-stack Node.js) |
| Type de vulnérabilité | Contournement d'autorisation / Autorisation inappropriée (CWE-863) |
| Versions affectées | < 12.3.5, < 13.5.9, < 14.2.25, < 15.2.3 |
| Versions corrigées | 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 et supérieures |
| Niveau de gravité | Critique / Élevé (le score exact dépend de la page NVD) |
Après la divulgation de cette vulnérabilité, de nombreux panneaux d'administration, callbacks de paiement et API internes en production ont été contournés. Metasploit et ProjectDiscovery Nuclei ont tous deux intégré des modules de détection. Il s'agit de l'une des vulnérabilités de « contournement d'autorisation au niveau framework » les plus représentatives de 2025.
Next.js permet d'écrire la « logique d'authentification » dans un middleware, par exemple :
export function middleware(request) {
if (!isLogin(request)) return NextResponse.redirect("/login"); // Non connecté → bloquer
return NextResponse.next();
}
Le problème est que Next.js s'appuie en interne sur un en-tête de requête que le client peut falsifier pour déterminer si « cette requête a déjà exécuté le middleware » :
x-middleware-subrequest: middleware
Dans les versions affectées, si une requête externe transporte cet en-tête interne, Next.js croit à tort que le middleware a déjà été exécuté, et l'intégralité du middleware d'authentification est donc ignorée. L'attaquant n'a besoin d'aucun compte : il lui suffit d'envoyer cet en-tête pour accéder directement (code 200) à des routes protégées comme /admin — or la page elle-même fait généralement confiance au middleware et n'effectue pas de seconde vérification. Le contrôle d'autorisation est ainsi neutralisé (erreur de frontière de confiance).
💡 La valeur la plus couramment utilisée dans les exploits publics consiste à répéter le chemin du middleware, par exemple
middleware:middleware:middleware:middleware:middleware; une valeur uniquemiddlewarene fonctionne pas dans certaines versions/structures de répertoires (c'est le cas constaté avec la version 14.2.24 de ce laboratoire). Ce PoC teste plusieurs valeurs candidates en boucle ; si l'une d'elles aboutit, le contournement est réussi.
CVE-2025-29927-PoC/
├── README.md # Ce document (explication de la vulnérabilité + tutoriel laboratoire VMware)
├── LICENSE # MIT
├── .gitignore
├── exploit.py # ★ PoC de validation en Python3, bibliothèque standard uniquement (exécutable sur Kali/toute machine)
├── target/ # ★ Laboratoire de vulnérabilité intégré (à copier sur la machine cible Ubuntu)
│ ├── package.json # Verrouille [email protected] (version affectée)
│ ├── middleware.js # Simule un « middleware d'authentification » de production réelle
│ ├── pages/
│ │ ├── index.js # Page d'accueil
│ │ ├── login.js # Page de connexion (démonstration de la redirection ici)
│ │ └── admin.js # ★ Panneau d'administration protégé, lit flag.txt côté serveur
│ ├── flag.txt # Drapeau du laboratoire : FLAG{...}
│ ├── setup.sh # Installation en une commande sur la cible : Node 20 + npm install + build
│ └── start.sh # Écoute sur 0.0.0.0:3000 en mode production
└── tests/
└── mock_target.py # Cible simulée sans Node (uniquement pour l'auto-test de développement)
┌───────────────────────────────────────────────────────────┐
│ VMware Workstation Pro 17 (hôte : Windows) │
│ Réseau : NAT (VMnet8 par défaut), les deux VM sur le même │
│ sous-réseau, ping mutuel possible │
│ │
│ ┌──────────────────┐ ┌─────────────────────┐ │
│ │ Cible Ubuntu 24.04│ │ Attaque Kali Linux │ │
│ │ │ http │ │ │
│ │ Node 20 + Next │◄───────│ python3 exploit.py │ │
│ │ 14.2.24 :3000 │ GET │ │ │
│ └──────────────────┘ └─────────────────────┘ │
│ IP : <TARGET_IP> IP : <ATTACKER_IP> │
└───────────────────────────────────────────────────────────┘
| Usage | Image/Logiciel | Version recommandée |
|---|---|---|
| Logiciel de virtualisation | VMware Workstation Pro 17 (gratuit pour un usage personnel) | 17.x |
| Image de la machine cible | ISO Ubuntu Server LTS | 24.04.x |
| Machine d'attaque | Kali Linux (image VMware officielle préinstallée ou installation ISO) | 2025.x |
| (Optionnel) | 8 Go de RAM ou plus sur l'hôte, 50 Go d'espace disque ou plus | — |
Toutes les étapes suivantes s'exécutent sur la machine cible Ubuntu.
# Méthode A : pousser le projet sur votre GitHub puis le cloner (recommandé ; utilisez ceci si vous comptez le publier sur GitHub)
git clone https://github.com/<votre_nom_utilisateur>/CVE-2025-29927-PoC.git
cd CVE-2025-29927-PoC
# Méthode B : transfert scp depuis l'hôte
# scp -r CVE-2025-29927-PoC ubuntu@<TARGET_IP>:~/