CVE-2025-29927

Introduction

Ce document présente une recherche sur la vulnérabilité CVE-2025-29927, affectant le mécanisme Middleware dans le framework Next.js.
Next.js est un framework open-source populaire de Vercel pour le développement d'applications basées sur React. Il prend en charge le rendu côté serveur, la génération statique et un système de middleware flexible, utilisé pour le routage, les redirections, les en-têtes de sécurité et la vérification des droits d'accès.

En mars 2025, une vulnérabilité critique CVE-2025-29927 a été découverte, liée au traitement d'un en-tête de service interne de sous-requête.
Le cœur du problème est la possibilité de contourner les vérifications d'autorisation dans les applications où le contrôle d'accès est implémenté dans le middleware, en injectant une valeur spéciale dans l'en-tête HTTP x-middleware-subrequest. Si la sécurité repose uniquement sur le middleware, un attaquant peut accéder à des routes ou données protégées.

Versions concernées de Next.js et correctifs (selon les sources publiques et la documentation officielle) :

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

Les correctifs sont disponibles dans les versions 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.

Next.js est largement utilisé en production ; une vulnérabilité affectant la couche middleware (souvent utilisée pour l'authentification/l'autorisation et les politiques de sécurité) présente un risque pratique élevé.

Objectif du rapport

Analyser pas à pas la vulnérabilité et réaliser un cycle complet de recherche :

Collecte et structuration des informations.
Systématiser les sources publiques relatives à CVE-2025-29927 ; décrire l'essence du défaut, les conditions de déclenchement et les versions/patches confirmés.

Définition du CPE et des conditions de configuration.
Fournir la liste des CPE/versions et décrire les configurations dans lesquelles la vulnérabilité se reproduit (par exemple, déploiement auto-hébergé et autorisation au niveau du middleware).

Démonstration sécurisée.
Préparer une démo reproductible dans un environnement de test (sans actions destructrices), confirmant le contournement du middleware dans les versions vulnérables.

Méthodes de vérification de masse.
Décrire et implémenter trois approches sécurisées :

• nuclei (mode actif avec impact minimisé),
• nuclei (mode passif basé sur les versions/indices indirects),
• script Python/Go personnalisé (vérification active multithread sur des hôtes de test).

Essence de la vulnérabilité

• Cause première. Dans Next.js, l'en-tête de service x-middleware-subrequest est utilisé pour suivre les sous-requêtes internes et éviter la récursion dans le middleware. Dans les branches vulnérables, les clients externes peuvent injecter cet en-tête avec une valeur « attendue » — et le moteur d'exécution saute l'exécution du middleware, transmettant la requête directement au gestionnaire de route.

• Rôle de l'en-tête. L'en-tête x-middleware-subrequest était initialement conçu comme un indicateur interne indiquant que la requête HTTP actuelle a été lancée par le framework lui-même comme une sous-requête intermédiaire, et non directement par l'utilisateur.
  Il est nécessaire au bon fonctionnement des mécanismes internes de Next.js : outre le routage, ce drapeau aide à éviter une récursion infinie en « marquant » chaque couche intermédiaire invoquée.
  Mais c'est précisément cette logique qui a créé une faille de sécurité involontaire : un client qui ajoute lui-même un tel en-tête peut amener le système à traiter sa requête comme interne et ainsi contourner les vérifications d'autorisation.

• Évolution de la logique.

  • Dans les versions antérieures, l'en-tête est interprété comme une liste de valeurs séparées par deux-points, et le mécanisme le compare au nom/chemin du middleware actif.
  • Dans les branches plus récentes, une protection contre la récursion infinie a été ajoutée sous la forme d'un compteur de profondeur ; lorsque le seuil (par défaut 5) est atteint, le middleware est également sauté. Ce mécanisme peut être trompé si l'en-tête est formaté « comme si » la chaîne de sous-requêtes avait déjà épuisé la limite.

Impact

• Confidentialité et intégrité. Accès non autorisé à des pages ou API protégées lorsque le contrôle d'accès est implémenté uniquement au niveau du middleware ; modification potentielle des données via des endpoints protégés.
• Disponibilité. Des effets secondaires comme l'empoisonnement du cache peuvent entraîner une mise en cache incorrecte et une dégradation de la disponibilité dans certaines configurations.

CPE et conditions de configuration

CPE officiels (CPE 2.3)

Les enregistrements NVD actuels mentionnent le produit Vercel Next.js avec le logiciel cible node.js. Pour les branches vulnérables, les configurations suivantes sont applicables (plages de versions définies au niveau des configurations CPE dans NVD) :

Remarque : la description CVE indique également qu'en général, « à partir de 11.1.4 et jusqu'à 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 », la vulnérabilité se reproduit si les conditions ci-dessous sont remplies.

Conditions de pertinence dans un environnement de production

• Le contrôle d'accès (authentification/autorisation) est implémenté dans le middleware et n'est pas dupliqué dans les gestionnaires/backend.
• Déploiement auto-hébergé (par exemple, next start, build avec output: 'standalone') ou tout environnement où le middleware s'exécute sur les requêtes entrantes sans filtrage périmétrique des en-têtes de service.
• Absence de moyens externes rejetant les requêtes utilisateur avec x-middleware-subrequest (par exemple, règles WAF).

Mécanisme interne de x-middleware-subrequest

Afin d'éviter une récursion infinie du code intermédiaire, le moteur d'exécution forme et lit l'en-tête de service :

1. La valeur de l'en-tête est interprétée comme une chaîne avec des éléments séparés par deux-points : — ce qui donne un tableau de « sous-requêtes ».
2. Ensuite, le moteur vérifie :
   • si le nom/chemin du middleware actif apparaît dans ce tableau (dans les anciennes branches, cela entraînait un saut immédiat via NextResponse.next()),
   • ou si la profondeur de récursion maximale est atteinte (dans les nouvelles branches, une limite est appliquée, par défaut 5), et alors le middleware est également sauté.
3. Pour se protéger contre la falsification, les correctifs ajoutent un identifiant de sous-requête distinct (x-middleware-subrequest-id), lié à la session en cours du processus ; s'il ne correspond pas, le x-middleware-subrequest entrant est nettoyé côté serveur.

Méthode d'exploitation

Un attaquant envoie une requête HTTP à l'application Next.js cible, en y ajoutant l'en-tête de service x-middleware-subrequest.
La valeur indique le chemin du fichier middleware — par exemple pages/_middleware, middleware ou src/middleware.
La valeur nécessaire dépend de la version de Next.js utilisée et de la structure du projet.

Lorsque cette requête atteint l'application, la logique interne du framework la perçoit comme une sous-requête interne et suppose que la couche intermédiaire a déjà été exécutée.
En conséquence, les contrôles d'authentification et d'autorisation qui se produisent normalement dans le middleware sont effectivement ignorés.

PoC / Exploit

Important : ce matériel est fourni uniquement pour vérifier le correctif et modéliser le risque dans un environnement de test fermé.
Toute vérification dans une infrastructure de production n'est possible qu'avec l'autorisation du propriétaire des ressources.

Principe général

Next.js utilise l'en-tête de service x-middleware-subrequest pour marquer les sous-requêtes internes et empêcher l'exécution récursive du middleware.
Lors du traitement de la requête, la valeur de l'en-tête est divisée par le caractère : et comparée au nom du middleware actif.
Dans les nouvelles versions, une limite de profondeur est ajoutée (MAX_RECURSION_DEPTH, généralement 5).
Si la condition (correspondance du nom ou atteinte de la limite) est remplie, Next.js saute le middleware et transmet la requête plus loin.
Un attaquant peut formuler une valeur d'en-tête correcte, imitant une sous-requête interne.

Exploitation par version

1️⃣ Versions antérieures à 12.2 : Pages Router et _middleware.*

• Les fichiers middleware étaient nommés _middleware.js/ts et placés dans le répertoire pages/.
• La valeur de l'en-tête doit correspondre au chemin du fichier, par exemple : x-middleware-subrequest: pages/_middleware

2️⃣ Versions 12.2 – 13.0.0 : middleware.* racine

• À partir de la version 12.2, le soulignement a été supprimé du nom : le fichier est devenu middleware.js/ts.
• Il peut se trouver à la racine du projet ou à la racine du répertoire /src.
• Pour contourner le middleware, on utilise l'en-tête : x-middleware-subrequest: middleware ou x-middleware-subrequest: src/middleware

3️⃣ Versions 13.x et ultérieures : limite de profondeur de récursion

• Une vérification de profondeur a été ajoutée : la valeur de l'en-tête est divisée par :, et si le nombre de répétitions du nom du middleware ≥ 5,
  Next.js considère que la condition de récursion est atteinte et saute le middleware via NextResponse.next().
• Pour l'attaque, l'en-tête est formaté ainsi : x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware ou x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

Particularités dans Next.js 15.x

Dans les versions 15.x, les développeurs ont retravaillé la logique pour empêcher les appels récursifs infinis.
Lorsqu'un middleware se déclenche sur un chemin (par exemple /api/*), Next.js obtient une autre URL qui déclenche également le même middleware.
Le framework compte le nombre de déclenchements via l'en-tête x-middleware-subrequest.
Si le nombre d'appels atteint le seuil défini (MAX_RECURSION_DEPTH, par défaut 5), les appels ultérieurs au middleware sont bloqués.
Un attaquant peut exploiter ce comportement en indiquant à l'avance dans l'en-tête une valeur avec le nombre de répétitions nécessaire, atteignant ainsi artificiellement la limite de profondeur — en conséquence, le middleware est complètement ignoré.

Exemple de requête

pour les anciennes branches, la valeur de l'en-tête est choisie selon les variantes ci-dessus

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

Pourquoi cela fonctionne

x-middleware-subrequest a été conçu comme un mécanisme interne de protection contre la récursion infinie.
Mais dans les versions vulnérables, il n'y avait pas de filtrage des requêtes externes : le client pouvait falsifier l'en-tête,
remplir la condition de saut (correspondance du nom ou atteinte de la limite de profondeur)
et accéder directement au gestionnaire de la route protégée.

Lancement du banc de test

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

Test :

(exemple basé sur Next.js 15.2.2 ; pour les autres branches, choisissez la valeur de l'en-tête selon le tableau dans la section PoC)

1. Requête 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. Requête avec l'en-tête 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

Recommandations de protection

• Mettez à jour Next.js au moins vers les versions 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3.
• Si la mise à jour est retardée — filtrez ou rejetez l'en-tête externe x-middleware-subrequest au niveau du WAF/proxy.
• Dupliquez les vérifications critiques d'autorisation dans les gestionnaires d'API, et pas seulement dans le middleware.

Modèle Nuclei pour les tests

• Ce modèle combine une vérification passive et active des applications Next.js.
• Il analyse passivement les en-têtes et les redirections pour détecter des signes de Next.js et un éventuel comportement du middleware.
• Il teste activement le contournement du middleware à l'aide d'un en-tête X-Middleware-Subrequest spécialement formaté.
• Il utilise plusieurs payloads, ce qui augmente la probabilité de détection de la vulnérabilité — environ 60% dans des conditions de test standard.

⚠️ Attention : le modèle est destiné uniquement aux tests sur vos propres cibles ou des cibles autorisées. L'utiliser sur des services tiers sans le consentement des propriétaires est illégal.

Script de test de masse

• Le script prend en charge le multithreading, ce qui permet de scanner rapidement un grand nombre de services et de chemins.
• Il prend en charge la saisie de listes de cibles et de chemins via des fichiers.

python3 scan.py --targets-file FICHIER_CIBLES --paths-file FICHIER_CHEMINS --threads NOMBRE_THREADS