Plateforme
27 mars 2025 CVE Nicolas D
CVE-2025-29927 - Next.js

Ce contenu vous plait
Partagez-le sur les réseaux
Une vulnérabilité récemment identifiée, CVE-2025-29927, affecte le framework Next.js, un choix populaire pour la création d’applications web basées sur React. Cette faille de sécurité critique, à laquelle a été attribué un score CVSS de 9.1, permet aux attaquants de contourner les mécanismes d’autorisation mis en place via le middleware de Next.js, leur offrant potentiellement un accès non autorisé à des ressources sensibles.
Versions concernées
Cette vulnérabilité affecte les versions suivantes de Next.js :
De la version 11.1.4 à 13.5.6
Versions 14.x antérieures à 14.2.25
Versions 15.x antérieures à 15.2.3
Cause principale
Le problème provient de la gestion de l’en-tête x-middleware-subrequest
par Next.js.
Cet en-tête est utilisé en interne par Next.js pour éviter les boucles infinies de requêtes.
Les attaquants peuvent manipuler cet en-tête afin de contourner le middleware de sécurité, permettant ainsi à des requêtes d’atteindre des routes protégées sans vérification d’autorisation adéquate.
En injectant cet en-tête dans une requête malveillante, un attaquant peut exploiter la dépendance du système à l’autorisation basée sur le middleware.
Une vulnérabilité difficile à détecter
Identifier et vérifier cette vulnérabilité peut être particulièrement complexe. Pourquoi ?
Parce qu’elle n'affecte que les applications reposant uniquement sur l’autorisation via middleware. Il s’agit donc d’une configuration très spécifique mise en place par les développeurs ou les administrateurs systèmes.
De plus, si des couches de sécurité supplémentaires sont présentes, l’exploitation peut ne pas être immédiatement visible.
Pour détecter l’exploitabilité réelle de cette vulnérabilité, il est essentiel d’avoir une compréhension approfondie de l’application et de son architecture. Cela implique :
L’analyse de la configuration spécifique et de l’installation complète du framework Next.js
L’automatisation de la détection des pages protégées par le mécanisme de sécurité de Next.js
L’analyse rigoureuse des résultats obtenus
Une détection impossible avec les scanners classiques
Les scanners de sécurité classiques, les solutions EASM ou les évaluations de sécurité traditionnelles ne permettent pas d’identifier cette vulnérabilité avec précision.
Seuls un pentester ou des hunters peuvent le faire manuellement.
Patrowl est la seule solution permettant d’évaluer cette vulnérabilité à grande échelle, avec précision, et de manière continue sur tous vos actifs exposés.
Notre approche pour identifier les applications vulnérables
Nous avons suivi une approche en entonnoir :
Exclure les applications ne reposant pas sur le framework Next.js
Exclure les versions non vulnérables
Explorer en profondeur les applications restantes pour identifier les endpoints
Tester des charges malveillantes sur ces endpoints
Essayer de sauter ces étapes et envoyer des payloads aléatoires sur toutes les applications surveillées serait inefficace, trop verbeux et impraticable.
Identification des applications Next.js
Plusieurs critères peuvent aider à identifier les applications Next.js :
Certains serveurs répondent avec un en-tête détaillé :X-Powered-By: Next.js

Par défaut, les ressources générées par Next.js (par exemple, les fichiers JS et CSS) sont stockées dans le répertoire
/_next/static
:

Les applications Next.js exposent un objet JavaScript global next
dans le navigateur. Cet objet contient un champ version
qui indique la version de Next.js utilisée par l’application :

En combinant ces techniques, nous avons réussi à identifier, avec une forte confiance, les applications Next.js exécutant une version vulnérable.
Analyse approfondie
À ce stade, tous les clients exposant une application Next.js exécutant une version vulnérable ont été alertés afin qu’ils mettent rapidement à jour leurs produits.
Cependant, exécuter une version vulnérable ne signifie pas nécessairement que la vulnérabilité peut être exploitée sur l’application. En effet, nous n’avons pas encore confirmé que le middleware défectueux est utilisé ni identifié de chemin vulnérable.
Vérification des chemins vulnérables
Avant tout, nous devons déterminer si un chemin donné est vulnérable. Un bon template Nuclei a été publié par Project Discovery :
🔗 CVE-2025-29927 Nuclei Template
Bien que ce template soit efficace, il ne renverra des résultats que s’il est exécuté sur un chemin protégé par le middleware d’authentification.
La difficulté de trouver des chemins protégés
Identifier ces chemins est complexe. Se baser uniquement sur une stratégie de crawling s’avère inefficace :
De nombreuses applications Next.js sont des SPA (Single Page Applications). Or, le crawling d’une SPA est notoirement difficile car il nécessite souvent un navigateur headless, ce qui est lent et très consommateur de ressources.
Les chemins potentiellement vulnérables sont, par définition, protégés par un mécanisme d’autorisation et ne sont donc pas accessibles aux crawlers anonymes.
Tests avec un template de détection
Nous avons tout de même tenté d’exécuter le template Nuclei sur les chemins identifiés via le crawling des applications. Comme prévu, les résultats ont été…

Mais nous pouvons faire bien mieux !
Chez Patrowl, nous avons l’habitude de trouver des points d’entrée cachés, en particulier pour les applications SPA (Single Page Applications).
L’idée clé est que presque tous les chemins d’une SPA peuvent être retrouvés dans les fichiers JavaScript qu’elle charge. Ainsi, en analysant le code source de ces fichiers, nous pouvons découvrir des chemins cachés qu’un simple crawling ne permettrait pas d’identifier.
Notre approche avancée
Pour cette technique, nous avons développé un outil basé sur TreeSitter, avec :
Des requêtes personnalisées
Un mécanisme avancé de résolution des variables
L’objectif est d’être le plus précis possible malgré la complexité du code JavaScript minifié que nous analysons.
Grâce à cette approche, nous pouvons identifier des patterns comme :
const BASE_API = "/api/v1";
// [...]
function getUser(id) {
http.get(BASE_API+"/user/"+id);
// [...]
}
L’exécution de notre outil sur ce contenu JavaScript renverra :
GET /api/v1/user/{id}
Donc, finalement, en utilisant notre compréhension de la vulnérabilité et de la manière de trouver les points d’entrée, nous l’automatisons simplement pour chaque application potentiellement vulnérable :
Récupérer tous les fichiers
.js
chargés par l’applicationLes analyser pour trouver les points d’entrée à l’aide de notre outil d’analyse JS
Exécuter le template de détection sur ces points d’entrée
Cette approche est efficace, évite de solliciter inutilement les applications de nos clients, scalable et facilement automatisable ! Tous nos clients savent désormais, de manière précise, s’ils sont vulnérables ou non.
Comment corriger cette vulnérabilité (si vous n'avez pas encore Patrowl)
1. Mettre à jour Next.js vers une version corrigée :
Pour Next.js 15.x, mettez à jour vers la version 15.2.3 ou ultérieure.
Pour Next.js 14.x, mettez à jour vers la version 14.2.25 ou ultérieure.
Pour Next.js 13.x, mettez à jour vers la version 13.5.9 ou ultérieure.
Pour Next.js 12.x, mettez à jour vers la version 12.3.5 ou ultérieure.
Ces versions contiennent des correctifs qui résolvent la vulnérabilité.
2. Mise en œuvre d'une atténuation temporaire si la mise à jour immédiate n'est pas possible :
Configurez votre serveur web, votre WAF ou votre proxy pour bloquer ou supprimer l’en-tête
x-middleware-subrequest
des requêtes externes.Surveillez toute requête suspecte contenant cet en-tête (par exemple, des attaques par force brute sur des chemins spécifiques, comme expliqué dans cet article).
Recommandations :
Priorisez la mise à jour de Next.js vers la dernière version corrigée pour remédier complètement à la vulnérabilité.
Examinez les configurations de votre middleware pour vous assurer que les vérifications d’autorisation sont robustes et non uniquement dépendantes des composants potentiellement vulnérables.
Surveillez les communications officielles de Next.js pour toute mise à jour ou alerte supplémentaire concernant cette vulnérabilité.
Ou, la meilleure option : contactez-nous si vous voulez que vos actifs soient protégés en continu par Patrowl !