CVE-2025-29927 : la faille du middleware Next.js

CVE-2025-29927 est une faille critique (CVSS 9,1) du framework Next.js. Elle permet de contourner les contrôles d'autorisation placés dans le middleware, simplement en ajoutant un en-tête HTTP nommé x-middleware-subrequest à la requête. Toutes les branches récentes sont concernées avant les correctifs publiés le 21 mars 2025 : 12.3.5, 13.5.9, 14.2.25 et 15.2.3. Ce qu'il faut faire maintenant : mettre à jour Next.js, ou bloquer cet en-tête si la mise à jour n'est pas possible tout de suite.

Ce qui te concerne

• Gravité : critique, CVSS 9,1. Exploitable à distance, sans authentification, sans interaction de l'utilisateur.
• Faiblesse : CWE-863 (autorisation incorrecte).
• Publication : la CVE est publique depuis le 21 mars 2025.
• Probabilité d'exploitation : score EPSS de 99,2 % (percentile 100).
• Hébergement : les apps sur Vercel sont protégées automatiquement (le routage y est découplé). Netlify et Cloudflare Workers n'ont jamais été affectés. Le self-hosted (next start, output: 'standalone') est concerné.

Next.js 11.x n'a pas reçu de correctif : la branche est hors support. Le contournement s'applique (voir plus bas).

Pourquoi c'est sérieux pour toi

Le middleware est l'endroit où beaucoup d'apps générées par l'IA placent leur contrôle d'accès : vérifier un cookie, rediriger vers la page de connexion, bloquer les routes admin. C'est pratique, parce que ce code s'exécute avant le rendu. Si tu as construit ton app avec Lovable ou un autre outil d'IA, il y a de bonnes chances que ta vérification d'authentification vive exactement là. Une app qui se fait contourner sur ce point ouvre d'un coup ses pages admin, ses dashboards et ses routes API.

C'est la même famille de risque qu'une faille IDOR : l'autorisation est vérifiée au mauvais endroit, ou pas du tout, et un inconnu finit par lire ce qui ne lui était pas destiné.

Le mécanisme, expliqué simplement

Next.js exécute le middleware avant le routage et le cache. Problème : le middleware tourne dans un processus séparé de celui qui rend la page. Pour éviter qu'il se rappelle lui-même à l'infini (une boucle de sous-requêtes), Next.js utilise un en-tête interne, x-middleware-subrequest. Quand le middleware fait lui-même une requête interne vers l'app, cet en-tête signale au routeur : « le middleware est déjà passé, saute-le ».

La faille tient à un détail : cet en-tête était accepté sans validation. N'importe qui peut donc l'envoyer depuis l'extérieur. Le routeur le voit, croit à une sous-requête interne légitime, et saute le middleware. Résultat : le contrôle d'autorisation ne s'exécute jamais, alors que la page ou la route est bien servie.

Le correctif ajoute une validation de cet en-tête : s'il ne vient pas d'une vraie sous-requête interne, il est filtré avant d'atteindre le routeur.

Le prompt de correction à coller dans ton agent

Corrige la faille CVE-2025-29927 (contournement du middleware Next.js) dans ce projet.

1. Mets à jour Next.js vers une version corrigée selon la branche du projet (regarde la dépendance "next" dans package.json) :
   - 15.x → npm install next@15.2.3
   - 14.x → npm install next@14.2.25
   - 13.x → npm install next@13.5.9
   - 12.x → npm install next@12.3.5

2. Si le projet est en Next.js 11.x (aucun correctif disponible), ajoute au niveau du reverse proxy, du WAF ou d'un middleware d'entrée une règle qui supprime l'en-tête x-middleware-subrequest de toute requête entrante avant qu'elle n'atteigne le serveur Next.js.

3. Vérifie ensuite que :
   - "npm ls next" renvoie bien une version corrigée (>= 15.2.3, >= 14.2.25, >= 13.5.9 ou >= 12.3.5) ;
   - les routes protégées par le middleware refusent toujours l'accès sans session valide ;
   - aucun scan de sécurité ne remonte plus la CVE-2025-29927.

Si tu es sur Vercel, la plateforme te protège déjà. Mets quand même à jour : le jour où tu déploies ailleurs ou en self-hosted, tu reprends le risque.

Ne mets pas toute ta sécurité dans le middleware

Cette faille rappelle une règle simple : le middleware est une première porte, pas la seule. Une app solide vérifie l'autorisation à plusieurs niveaux.

• Dans le middleware, pour rediriger tôt les visiteurs non connectés.
• Côté serveur, dans le gestionnaire de route, là où la donnée est réellement lue.
• Au plus près des données, avec du row level security sur Supabase.

Si une couche tombe, les autres tiennent.

Questions fréquentes

Suis-je concerné si je n'utilise pas le middleware pour l'authentification ?

La faille ne se déclenche que si un contrôle d'autorisation est fait dans le middleware. Si ton middleware ne fait que réécrire des URLs ou rediriger des cas non sensibles, le risque est limité. La mise à jour reste à faire : tu peux ajouter un contrôle dans le middleware demain sans y repenser.

Je suis sur Vercel, est-ce que je dois faire quelque chose ?

Vercel protège automatiquement les apps hébergées chez lui, car son routage est découplé de celui de Next.js. Netlify et Cloudflare Workers n'ont jamais été affectés. Tu dois quand même mettre à jour pour tes déploiements hors plateforme, et pour rester propre si tu changes d'hébergeur.

Je suis en Next.js 11, que faire ?

Next.js 11 est hors support et n'a pas reçu de correctif. Deux options : bloquer l'en-tête x-middleware-subrequest en amont (reverse proxy ou WAF), ou migrer vers une branche maintenue. La migration est la solution durable.

Comment vérifier que mon app n'a pas déjà été touchée ?

Regarde tes logs d'accès à la recherche de requêtes portant l'en-tête x-middleware-subrequest. Vérifie aussi que tes routes protégées (admin, dashboard, API) n'ont pas reçu d'accès sans session. C'est un contrôle à faire sur ton propre site, sans rien exécuter contre celui des autres.

Le middleware peut-il suffire à protéger mes routes ?

Non. Utilise-le pour rediriger tôt, mais vérifie l'autorisation au plus près de la donnée : dans la route, et avec du row level security sur Supabase. C'est le seul moyen de tenir si le middleware est contourné.

Sources

• GitHub Security Advisory — GHSA-f82v-jwr5-mffw
• NVD — CVE-2025-29927
• Vercel — Postmortem on Next.js Middleware bypass

Avant de déployer, scanne ton app avec Rustine. Il regarde ton site comme le ferait un inconnu, montre ce qui fuit avec la preuve (la requête et ce qu'elle renvoie), et te donne le correctif à coller dans ton agent de code. Scan rapide gratuit sur rustine.io.