CVE-2025-29927 – <\/p>\n
Le 21 mars 2025, les mainteneurs de Next.js ont annonc\u00e9 une nouvelle vuln\u00e9rabilit\u00e9 permettant de contourner les m\u00e9canismes d\u2019autorisation\u00a0: CVE-2025-29927. Cette vuln\u00e9rabilit\u00e9 peut \u00eatre facilement exploit\u00e9e afin de contourner les m\u00e9canismes d\u2019autorisation. Dans certains cas, son exploitation peut \u00e9galement entra\u00eener un empoisonnement du cache et un d\u00e9ni de service.
\nQuelles versions de Next.js sont concern\u00e9es\u00a0?
\nNext.js 15.x \u2013 \u00e0 partir de la version 15.0.0 jusqu’\u00e0 la version 15.2.2 incluse.<\/p>\n
Next.js 14.x \u2013 \u00e0 partir de la version 14.0.0 jusqu’\u00e0 la version 14.2.24 incluse.<\/p>\n
Versions ant\u00e9rieures de Next.js \u2013 \u00e0 partir de la version 11.1.4 jusqu’\u00e0 la version 13.5.6 incluse.
\nSc\u00e9narios d\u2019attaque pour la CVE-2025-29927
\nPour que cette vuln\u00e9rabilit\u00e9 puisse \u00eatre exploit\u00e9e, le serveur Next.js cibl\u00e9 doit utiliser un middleware Next.js. Cela implique la pr\u00e9sence d\u2019un fichier middleware.js ou middleware.ts (_middleware.js ou _middleware.ts\u00a0 pour les anciennes versions de Next.js). Ce fichier d\u00e9finit et exporte la fonction de middleware contenant la logique ex\u00e9cut\u00e9e \u00e0 la r\u00e9ception de chaque requ\u00eate HTTP.
\nContournement des m\u00e9canismes d\u2019autorisation
\nIl s\u2019agit du sc\u00e9nario d\u2019exploitation le plus probable pour CVE-2025-29927.<\/p>\n
Ce sc\u00e9nario concerne les serveurs Next.js cibl\u00e9s qui utilisent la fonctionnalit\u00e9 de middleware pour effectuer les contr\u00f4les d\u2019autorisation (et dont l\u2019application sous-jacente n\u2019utilise aucune autre couche d\u2019autorisation).<\/p>\n
Sc\u00e9nario avec un middleware d\u2019autorisation sans exploitation de la CVE-2025-29927<\/p>\n
Sc\u00e9nario avec un middleware d\u2019autorisation et exploitation de la CVE-2025-29927<\/p>\n
D\u00e9ni de service par empoisonnement du cache
\nLe middleware Next.js peut \u00e9galement faciliter la localisation des sites web. Il peut, par exemple, rediriger automatiquement les utilisateurs en fonction de leur emplacement, en ajoutant \/en pour les anglophones ou \/fr pour les visiteurs francophones. Si une personne exploite la CVE-2025-29927 et contourne le middleware charg\u00e9 de ces redirections, elle n\u2019acc\u00e9dera pas \u00e0 une page localis\u00e9e, mais \u00e0 la racine du site web (\/), pour laquelle les d\u00e9veloppeurs n\u2019ont jamais cr\u00e9\u00e9 de page. Le r\u00e9sultat\u00a0? Une erreur 404 ou une erreur serveur 500, selon la configuration.<\/p>\n
Si le site utilise un CDN ou une autre couche de mise en cache, ces r\u00e9ponses d\u2019erreur peuvent \u00eatre enregistr\u00e9es dans le cache et pr\u00e9sent\u00e9es aux visiteurs suivants. Une fois ces r\u00e9ponses mises en cache, les utilisateurs l\u00e9gitimes risquent de voir des pages d\u00e9fectueuses partout dans le monde. Cela provoque une panne auto-inflig\u00e9e qui compromet gravement la disponibilit\u00e9 du service, sans qu\u2019une seule ligne de code ait \u00e9t\u00e9 modifi\u00e9e.<\/p>\n
Sc\u00e9nario avec un middleware de redirection sans exploitation de la CVE-2025-29927
\n\u00a0<\/p>\n
Sc\u00e9nario avec un middleware de redirection et exploitation de la CVE-2025-29927
\n\u00a0
\nComprendre le middleware Next.js
\nLe middleware Next.js est une fonctionnalit\u00e9 puissante, introduite dans Next.js v12, qui permet aux d\u00e9veloppeurs d\u2019ex\u00e9cuter du code avant qu\u2019une requ\u00eate ne soit finalis\u00e9e. Ex\u00e9cut\u00e9 \u00e0 la p\u00e9riph\u00e9rie du r\u00e9seau, plus pr\u00e8s de l\u2019utilisateur que le code traditionnel c\u00f4t\u00e9 serveur, le middleware peut modifier les en-t\u00eates de r\u00e9ponse, r\u00e9\u00e9crire ou rediriger les requ\u00eates et, surtout, mettre en \u0153uvre des contr\u00f4les d\u2019authentification et d\u2019autorisation.<\/p>\n
Dans Next.js, le middleware s\u2019ex\u00e9cute avant le rendu et peut \u00eatre configur\u00e9 de mani\u00e8re \u00e0 s\u2019activer sur des chemins sp\u00e9cifiques gr\u00e2ce aux param\u00e8tres matcher.<\/p>\n
Voici quelques exemples d\u2019utilisation du middleware Next.js\u00a0:<\/p>\n
\tV\u00e9rification des jetons d\u2019authentification
\n \tMise en place d\u2019un contr\u00f4le d\u2019acc\u00e8s bas\u00e9 sur les r\u00f4les
\n \tRedirection des utilisateurs non authentifi\u00e9s<\/p>\n
Une impl\u00e9mentation typique de middleware Next.js qui effectue l\u2019authentification pourrait ressembler \u00e0 ceci\u00a0:<\/p>\n
import { NextResponse } from ‘next\/server’
\n import type { NextRequest } from ‘next\/server’<\/p>\n
export function middleware(request: NextRequest) {
\n \/\/ R\u00e9cup\u00e9rer le jeton de l\u2019utilisateur dans les cookies
\n const token = request.cookies.get(‘token’).value<\/p>\n
\/\/ V\u00e9rifier que l\u2019utilisateur est authentifi\u00e9
\n const isAuthenticated = validateToken(token)<\/p>\n
\/\/ Si l\u2019utilisateur n\u2019est pas authentifi\u00e9, le rediriger vers la page de connexion
\n if (!isAuthenticated) {
\n return NextResponse.redirect(new URL(‘\/login’, request.url))
\n }<\/p>\n
\/\/ Poursuivre vers la route prot\u00e9g\u00e9e si l\u2019utilisateur est authentifi\u00e9
\n return NextResponse.next()
\n }<\/p>\n
\/\/ Configurer les routes qui utilisent ce middleware
\n export const config = {
\n matcher: [‘\/dashboard\/:path*’, ‘\/settings\/:path*’],
\n }
\n\u00a0<\/p>\n
Analyse technique de la CVE-2025-29927
\nLa CVE-2025-29927 r\u00e9v\u00e8le une faille critique dans la fa\u00e7on dont le middleware Next.js traite certains types de requ\u00eates. Cette faille peut permettre de contourner les m\u00e9canismes d\u2019authentification et d\u2019autorisation.<\/p>\n
Cette vuln\u00e9rabilit\u00e9 affecte les applications qui, dans certaines configurations, utilisent un middleware pour contr\u00f4ler les acc\u00e8s.<\/p>\n
Elle provient du traitement incoh\u00e9rent, par Next.js, des en-t\u00eates personnalis\u00e9s x-middleware-subrequest. Lorsque cet en-t\u00eate est inclus dans les requ\u00eates adress\u00e9es \u00e0 des routes prot\u00e9g\u00e9es, Next.js autorise \u00e0 tort la requ\u00eate \u00e0 contourner enti\u00e8rement l\u2019ex\u00e9cution du middleware. Cet en-t\u00eate force l\u2019environnement d\u2019ex\u00e9cution de Next.js \u00e0 ignorer la phase d\u2019\u00e9valuation du middleware, tout en continuant \u00e0 traiter le gestionnaire de la route sous-jacente.<\/p>\n
Pour exploiter cette vuln\u00e9rabilit\u00e9, il suffit \u00e0 un pirate d\u2019ajouter l\u2019en-t\u00eate x-middleware-subrequest \u00e0 ses requ\u00eates HTTP lorsqu\u2019il tente d\u2019acc\u00e9der \u00e0 des ressources prot\u00e9g\u00e9es. Par exemple, une requ\u00eate adress\u00e9e \u00e0 \/api\/admin\/users, normalement bloqu\u00e9e par les contr\u00f4les d\u2019autorisation du middleware, sera trait\u00e9e normalement si cet en-t\u00eate est pr\u00e9sent. Le serveur traite la requ\u00eate comme si le middleware l\u2019avait d\u00e9j\u00e0 examin\u00e9e et approuv\u00e9e, ce qui entra\u00eene un contournement complet des m\u00e9canismes de s\u00e9curit\u00e9. Cette manipulation de l\u2019en-t\u00eate peut \u00eatre facilement r\u00e9alis\u00e9e \u00e0 l\u2019aide des outils de d\u00e9veloppement d\u2019un navigateur, de commandes curl ou de scripts simples.<\/p>\n
Voici le code vuln\u00e9rable de la derni\u00e8re version affect\u00e9e (v15.2.2)\u00a0:<\/p>\n
export const run = withTaggedErrors(async function runWithTaggedErrors(params) {
\n const runtime = await getRuntimeContext(params)
\n const subreq = params.request.headers[`x-middleware-subrequest`] [1]
\n const subrequests = typeof subreq === ‘string’ ? subreq.split(‘:’) : [] [2]<\/p>\n
const MAX_RECURSION_DEPTH = 5
\n const depth = subrequests.reduce( [3]
\n (acc, curr) => (curr === params.name ? acc + 1 : acc),
\n 0
\n )<\/p>\n
if (depth >= MAX_RECURSION_DEPTH) { [4]
\n return {
\n waitUntil: Promise.resolve(),
\n response: new runtime.context.Response(null, {
\n headers: {
\n ‘x-middleware-next’: ‘1’,
\n },
\n }),
\n }
\n }
\n\u00a0<\/p>\n
\u00c0 l\u2019\u00e9tape [1], l\u2019en-t\u00eate x-middleware-subrequest est r\u00e9cup\u00e9r\u00e9 dans la requ\u00eate.
\n\u00c0 l\u2019\u00e9tape [2], sa valeur est divis\u00e9e \u00e0 l\u2019aide du d\u00e9limiteur :. Une fonction reduce compte ensuite, \u00e0 l\u2019\u00e9tape [3], le nombre d\u2019\u00e9l\u00e9ments de ce tableau (subrequests) qui correspondent au nom de fichier du middleware.
\nSi ce nombre est sup\u00e9rieur ou \u00e9gal \u00e0 MAX_RECURSION_DEPTH (dont la valeur est 5) \u00e0 l\u2019\u00e9tape [4], la fonctionnalit\u00e9 du middleware est contourn\u00e9e et la requ\u00eate est dirig\u00e9e vers sa route.
\nValeurs possibles de l\u2019en-t\u00eate d\u2019attaque<\/p>\n
Comme expliqu\u00e9 pr\u00e9c\u00e9demment, le nom de l\u2019en-t\u00eate vuln\u00e9rable est x-middleware-subrequest. La valeur qui lui est attribu\u00e9e d\u00e9pend de Next.js, car elle est d\u00e9finie en fonction de la valeur de middlewareInfo.name, qui correspond essentiellement au chemin du fichier middleware.js ou middleware.ts.<\/p>\n
Avant la version\u00a012.2, le fichier du middleware s\u2019appelait _middleware.js ou _middleware.ts et pouvait se trouver \u00e0 n\u2019importe quel niveau du sous-r\u00e9pertoire auquel nous tentions d\u2019acc\u00e9der. Dans notre cas, nous cherchons \u00e0 acc\u00e9der \u00e0 \/admin\/dashboard. La valeur de middlewareInfo.name pouvait donc \u00eatre pages\/_middleware ou pages\/admin\/_middleware. Si dashboard avait \u00e9t\u00e9 configur\u00e9 comme un r\u00e9pertoire contenant un fichier index.js,\u00a0cette valeur aurait \u00e9galement pu \u00eatre pages\/admin\/dashboard\/_middleware.<\/p>\n
Par exemple, si nous avions utilis\u00e9 notre code de d\u00e9monstration avec une version de Next.js ant\u00e9rieure \u00e0 la version\u00a012.2, nous aurions d\u00fb d\u00e9placer middleware.js dans le r\u00e9pertoire pages et le renommer _middleware.js. Notre requ\u00eate HTTP \u00ab\u00a0malveillante\u00a0\u00bb aurait alors \u00e9t\u00e9 la suivante\u00a0:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: pages\/_middleware
\n\u00a0<\/p>\n
\u00c0 partir de la version 12.2 et jusqu\u2019\u00e0 la version\u00a013, le fichier du middleware doit se trouver \u00e0 la racine du projet et porter le nom middleware.js\/middleware.ts. Pour attaquer ces versions de Next.js, la charge utile de l\u2019en-t\u00eate serait donc simplement middleware, et nous savons avec certitude que le fichier se trouve dans le r\u00e9pertoire racine.<\/p>\n
Si nous avions utilis\u00e9 une version de Next.js comprise entre les versions\u00a012.2 et 13, notre requ\u00eate \u00ab\u00a0malveillante\u00a0\u00bb aurait \u00e9t\u00e9 modifi\u00e9e comme suit\u00a0:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: middleware
\n\u00a0<\/p>\n
\u00c0 partir de la version 13 de Next.js, le contr\u00f4le de r\u00e9cursivit\u00e9 pr\u00e9sent\u00e9 pr\u00e9c\u00e9demment a \u00e9t\u00e9 mis en \u0153uvre. Un pirate doit donc attribuer \u00e0 l\u2019en-t\u00eate malveillant la valeur middleware:middleware:middleware:middleware:middleware afin de simuler cinq niveaux de r\u00e9cursivit\u00e9.<\/p>\n
Notre PoC utilisant cette version, voici un extrait de la requ\u00eate employ\u00e9e\u00a0:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware
\n\u00a0<\/p>\n
Gardez \u00e0 l\u2019esprit que, dans tous les cas, le code du middleware pouvait se trouver dans un r\u00e9pertoire src. Pour exploiter la vuln\u00e9rabilit\u00e9, il aurait alors \u00e9t\u00e9 n\u00e9cessaire d\u2019ajouter src au d\u00e9but des valeurs pr\u00e9sent\u00e9es pr\u00e9c\u00e9demment. Par exemple, si nous avions plac\u00e9 le code de notre PoC dans un r\u00e9pertoire src, notre charge utile aurait d\u00fb \u00eatre la suivante\u00a0:<\/p>\n
GET \/admin\/dashboard HTTP\/1.1
\n x-middleware-subrequest: src\/middleware:src\/middleware:src\/middleware:src\/middleware:src\/middleware.
\n\u00a0<\/p>\n
Exploitation de la CVE-2025-29927
\nComme toujours, il est pr\u00e9f\u00e9rable d\u2019observer une exploitation compl\u00e8te de la vuln\u00e9rabilit\u00e9 afin de comprendre quelles instances de Next.js seraient vuln\u00e9rables.<\/p>\n
Nous avons mis en place notre propre site web de PoC avec l\u2019arborescence suivante\u00a0:<\/p>\n
\u251c\u2500\u2500 middleware.js
\n\u251c\u2500\u2500 package-lock.json
\n\u251c\u2500\u2500 package.json
\n\u2514\u2500\u2500 pages
\n\u251c\u2500\u2500 admin
\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 dashboard.js
\n\u2514\u2500\u2500 index.js<\/p>\n
Tout d\u2019abord, notre page de connexion\u00a0:<\/p>\n
Voici ce qui se passe lorsqu\u2019un utilisateur non administrateur tente de se connecter\u00a0:<\/p>\n
Voici le tableau de bord d\u2019administration accessible \u00e0 l\u2019adresse \/admin\/dashboard avec les identifiants appropri\u00e9s\u00a0:<\/p>\n
Passons \u00e0 l’exploitation\u00a0: essayons d’abord d’envoyer une requ\u00eate GET \u00e0 \/admin\/dashboard sans l’en-t\u00eate malveillant\u00a0:<\/p>\n
Nous recevons une r\u00e9ponse 401 Unauthorized, car notre middleware s\u2019active et constate qu\u2019il ne s\u2019agit pas d\u2019un compte administrateur\u00a0:<\/p>\n
Essayons maintenant de r\u00e9p\u00e9ter la m\u00eame op\u00e9ration en ajoutant l\u2019en-t\u00eate x-middleware-subrequest\u00a0:<\/p>\n
Nous recevons une r\u00e9ponse 200 OK\u00a0!<\/p>\n
Gr\u00e2ce \u00e0 l\u2019aper\u00e7u web, nous pouvons \u00e9galement constater que nous avons bien re\u00e7u le document pr\u00e9sent\u00e9 pr\u00e9c\u00e9demment\u00a0:<\/p>\n
Correction de la CVE-2025-29927
\nMise \u00e0 niveau de la version
\nLa meilleure fa\u00e7on de corriger la CVE-2025-29927 consiste \u00e0 mettre \u00e0 niveau votre version de Next.js vers l\u2019une des versions corrig\u00e9es\u00a0:<\/p>\n
\t15.2.3
\n \t14.2.25<\/p>\n
Veillez \u00e0 identifier toutes les versions potentiellement vuln\u00e9rables, de la version\u00a011.1.4 \u00e0 la version\u00a013.5.6 incluse, ainsi que les versions\u00a014.2.24 et 15.2.2, puis \u00e0 les remplacer par cette nouvelle version corrig\u00e9e.
\nBlocage de l\u2019en-t\u00eate vuln\u00e9rable sur le serveur web
\nS\u2019il n\u2019est pas possible d\u2019effectuer la mise \u00e0 niveau, vous pouvez att\u00e9nuer la vuln\u00e9rabilit\u00e9 en configurant votre serveur web de mani\u00e8re \u00e0 supprimer l\u2019en-t\u00eate x-middleware-subrequest des requ\u00eates entrantes.<\/p>\n
Dans Apache, ajoutez la directive suivante au fichier .htaccess (mod_headers doit \u00eatre install\u00e9 et activ\u00e9)\u00a0:
\n <IfModule mod_headers.c>
\n RequestHeader unset x-middleware-subrequest
\n <\/IfModule>
\nDans NGINX, modifiez le fichier nginx.conf et ajoutez la directive proxy_set_header suivante au bloc server\u00a0:<\/p>\n
\u00a0proxy_set_header x-middleware-subrequest "";<\/p>\n
Par exemple\u00a0:
\n server {
\n\u00a0 listen 80;
\n\u00a0 server_name your_domain.com;
\n\u00a0 location \/ {
\n\u00a0 \u00a0 proxy_set_header x-middleware-subrequest "";
\n\u00a0 }
\n }
\nDans Express.js, ajoutez la directive suivante \u00e0 votre code source JavaScript\u00a0:
\n \/\/ Middleware permettant de supprimer l\u2019en-t\u00eate x-middleware-subrequest
\n app.use((req, res, next) => {
\n delete req.headers[‘x-middleware-subrequest’];
\n next();
\n });
\nBlocage de l\u2019en-t\u00eate vuln\u00e9rable \u00e0 l\u2019aide d\u2019un WAF
\nS\u2019il n\u2019est pas possible d\u2019effectuer la mise \u00e0 niveau, vous pouvez att\u00e9nuer la vuln\u00e9rabilit\u00e9 en utilisant un pare-feu d\u2019applications web afin de bloquer les requ\u00eates contenant l\u2019en-t\u00eate HTTP x-middleware-subrequest.
\nCorrection de la CVE-2025-29927 avec JFrog Xray et JFrog Advanced Security
\nComme toujours, JFrog Security Essentials (Xray) permet d\u2019identifier chaque occurrence de Next.js dans l\u2019ensemble de votre base de code et de vos artefacts compil\u00e9s, notamment les conteneurs Docker, les packages de d\u00e9p\u00f4ts et m\u00eame les fichiers binaires autonomes.<\/p>\n
JFrog Advanced Security a \u00e9galement \u00e9t\u00e9 mis \u00e0 jour avec un scanner d\u2019analyse contextuelle qui v\u00e9rifie automatiquement si votre d\u00e9ploiement Next.js est r\u00e9ellement vuln\u00e9rable \u00e0 la CVE-2025-29927, en d\u00e9terminant si un middleware Next.js est utilis\u00e9.<\/p>\n
Plateforme JFrog\u00a0: analyse contextuelle JFrog de la CVE-2025-29927 dans Next.js (cliquez sur l\u2019image pour l\u2019afficher en taille r\u00e9elle)<\/p>\n
Consultez le centre de recherche en s\u00e9curit\u00e9 de JFrog pour en savoir plus sur les derni\u00e8res CVE, vuln\u00e9rabilit\u00e9s et correctifs.<\/p>\n","protected":false},"excerpt":{"rendered":"
CVE-2025-29927 – Le 21 mars 2025, les mainteneurs de Next.js ont annonc\u00e9 une nouvelle vuln\u00e9rabilit\u00e9 permettant de contourner les m\u00e9canismes d\u2019autorisation\u00a0: CVE-2025-29927. Cette vuln\u00e9rabilit\u00e9 peut \u00eatre facilement exploit\u00e9e afin de contourner les m\u00e9canismes d\u2019autorisation. Dans certains cas, son exploitation peut \u00e9galement entra\u00eener un empoisonnement du cache et un d\u00e9ni de service. Quelles versions de Next.js …<\/p>\n","protected":false},"author":590,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[10529,10153],"tags":[11398,10000,11406,9999,11286],"class_list":["post-174412","post","type-post","status-publish","format-standard","hentry","category-communaute","category-securite-et-devsecops","tag-cve-2","tag-cve-analyse","tag-next-js","tag-securite-recherche","tag-vulnerabilites"],"yoast_head":"\n