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

URI CPE	Plage de versions vulnérable
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:*	11.1.4 ≤ v < 12.3.5
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:*	13.0.0 ≤ v < 13.5.9
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:*	14.0.0 ≤ v < 14.2.25
cpe:2.3:a:vercel:next.js:*:*:*:*:*:node.js:*:*	15.0.0 ≤ v < 15.2.3

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.