Les failles découvertes sur Next.js ont rappelé une réalité simple, une application créée avec les réglages par défaut n’est pas automatiquement protégée. Plusieurs vulnérabilités récentes touchent le middleware, l’authentification, React et certaines configurations serveur, avec des risques allant du contournement d’accès à l’exécution de code à distance. Voici un état des lieux clair, puis les actions à mener pour corriger, bloquer et surveiller.
En quelques lignes :
Je résume en une phrase : mettez à jour vos versions, bloquez les requêtes portant x-middleware-subrequest et inventoriez tous vos environnements pour réduire l’exposition et garder vos services fiables.
- Vérifiez la version déployée sur chaque instance avec npx next –version, npm ls next et pnpm why next.
- Appliquez les correctifs recommandés (par exemple 15.5.16+ ou 16.2.5+) et confirmez la présence du patch après déploiement.
- Bloquez en amont les requêtes contenant x-middleware-subrequest via proxy, WAF ou règles Cloud pour empêcher les contournements d’authentification.
- Durcissez l’accès aux métadonnées cloud (obliger IMDSv2 sur AWS) et, si besoin, désactivez temporairement les Server Actions et les rewrites personnalisés.
- Activez une Content Security Policy, les en-têtes de sécurité et du logging avec alertes pour détecter rapidement toute activité anormale.
Failles critiques connues sur Next.js : état des lieux
Les alertes publiées ces derniers mois montrent que Next.js est exposé à plusieurs familles de risques, parfois sur des versions très récentes. Le point commun est souvent le même, l’attaquant cherche à contourner une protection placée dans le middleware ou à exploiter une configuration trop ouverte.
La vulnérabilité la plus commentée reste CVE-2025-29927, un contournement d’authentification dans le middleware Next.js. Elle permet à un attaquant de passer outre les contrôles d’autorisation et d’atteindre des zones protégées sans authentification. Elle affecte les versions à partir de 11.1.4, avec correctifs appliqués pour 12.3.5, 13.5.9, 14.2.25 et 15.2.3. Selon les analyses techniques, les versions antérieures à 14.2.25 et les branches 15.x avant 15.2.3 restent exposées via l’en-tête x-middleware-subrequest.
Une autre alerte majeure concerne CVE-2026-44578, décrite comme critique, avec un risque d’exécution de code à distance et d’exposition de secrets serveur. Elle touche les versions antérieures à 15.5.16 dans la branche 13.4.13 à 15.5.16, ainsi que les versions antérieures à 16.2.5 dans la branche 16.0.0 à 16.2.5. Les versions considérées comme sûres sont donc 15.5.16+ et 16.2.5+. Des suivis de sécurité indiquent aussi qu’en dessous de 15.5.21 ou 16.2.11, une version peut rester exposée à au moins une CVE récente de la série correspondante.
Dans la même période, CVE-2025-55182 et CVE-2025-66478 ont également été signalées avec des risques d’exécution de code distant et d’affaiblissement de la configuration par défaut. À cela s’ajoute une faille commune à React et Next.js en 2025, qui impacte les versions 15.x et 16.x et peut être exploitée par défaut sur une application créée avec create-next-app, sans modification du code.
Le point à retenir est net, même une application Next.js standard, déployée en production, peut rester vulnérable si elle n’a pas été adaptée et mise à jour. Le middleware d’authentification est souvent ciblé, car l’attaque cherche précisément à éviter cette barrière.
Comment identifier et corriger les versions vulnérables
Avant toute remédiation, il faut savoir exactement ce qui est déployé. Trop d’équipes vérifient seulement le projet principal, alors que les versions critiques peuvent se cacher dans une préproduction, une démo, un outil interne ou un auto-hébergement oublié.
Pour dresser l’inventaire, les commandes les plus utiles sont npx next –version, npm ls next et pnpm why next. Elles permettent de vérifier la version installée, la dépendance réellement résolue et la présence éventuelle de versions indirectes. Il faut appliquer cette vérification à tous les environnements, pas uniquement à la production officielle.
Le tableau suivant récapitule les repères de versions les plus souvent cités pour les correctifs récents.
| Faille ou composant | Versions à éviter | Versions de référence sûres |
|---|---|---|
| CVE-2025-29927 | 11.1.4 à 15.2.2 selon la branche | 12.3.5, 13.5.9, 14.2.25, 15.2.3 et au-dessus |
| CVE-2026-44578 | 13.4.13 à 15.5.15, 16.0.0 à 16.2.4 | 15.5.16+, 16.2.5+, idéalement 15.5.21+ ou 16.2.11+ |
| React | Versions antérieures aux correctifs publiés | 19.0.1, 19.1.2, 19.2.1 selon la branche |
Pour certaines branches Next.js, d’autres repères sont régulièrement recommandés, comme 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 et 16.0.7. Un contournement temporaire via une version canary inférieure à 14.3 peut exister dans des cas isolés, mais il ne remplace pas une vraie mise à jour.
Protocole de correction des versions Next.js et React
La mise à jour doit suivre une logique simple, monter Next.js et React vers les versions corrigées correspondant à votre branche. Si vous êtes sur une version proche d’un correctif, vérifiez que le passage ne réintroduit pas une dépendance plus ancienne par effet de bord dans votre chaîne CI/CD.
Après la mise à jour, il faut confirmer que le patch est réellement présent dans l’environnement déployé. Ce point compte beaucoup, car des pipelines de déploiement peuvent parfois réécrire une version, restaurer un verrou ancien ou republier une image trop vieille. Je recommande donc une vérification post-déploiement systématique, avec contrôle de version et test fonctionnel de l’application.
Une bonne habitude consiste aussi à comparer l’environnement local, la préproduction et la production. Si l’un d’eux reste en retard, il devient une cible facile pour un test d’exploitation ou un rebond latéral.
Actions à mener immédiatement en cas d’impossibilité de mise à jour
Quand le correctif ne peut pas être déployé tout de suite, il faut limiter l’exposition sans attendre. Les mesures de mitigation recommandées par les éditeurs et la communauté reposent surtout sur le filtrage, le durcissement des métadonnées cloud et la réduction temporaire des fonctionnalités les plus sensibles.
La première mesure consiste à bloquer ou filtrer les requêtes externes contenant l’en-tête x-middleware-subrequest avant qu’elles n’atteignent l’application. Cette défense peut être mise en place au niveau d’un proxy inverse, d’un pare-feu applicatif ou d’un cloud provider. Sur nginx, on peut refuser les requêtes qui portent cet en-tête. Sur Cloudflare, Vercel ou une infrastructure proxy équivalente, l’idée reste la même, intercepter ces requêtes en amont.
Il faut également renforcer l’accès aux métadonnées cloud. Sur AWS, cela passe par l’obligation d’utiliser IMDSv2 via la politique d’instance EC2. Sur GCP et Azure, des restrictions analogues doivent limiter l’exposition des métadonnées à l’extérieur. Cette étape réduit les risques si une vulnérabilité donne un accès inattendu au serveur.
En parallèle, désactivez ou restreignez temporairement les Server Actions et les rewrites personnalisés s’ils ne sont pas indispensables. Les environnements utilisant un middleware d’authentification couplé à Turbopack, ou des configurations atypiques, doivent faire l’objet d’une attention particulière.
Une vérification manuelle simple permet aussi de tester l’exposition. L’idée est d’envoyer une requête vers une route protégée avec l’en-tête x-middleware-subrequest: middleware, puis d’observer et d’interpréter la réponse du serveur pour vérifier si l’accès est accordé sans contrôle d’authentification. Si la réponse contourne la logique attendue, l’instance doit être considérée comme à risque immédiat.
Points de vigilance à surveiller avant mise en production ou migration
Le périmètre à surveiller dépasse largement la production officielle. Les surfaces oubliées sont souvent les plus dangereuses, car elles sont moins documentées et moins contrôlées. Il faut donc recenser les applications auto-hébergées, les environnements de préproduction, les démos publiques, les outils internes accessibles en ligne et les POC qui sont devenus permanents.
La première vérification à effectuer est la version réellement déployée. Ensuite, contrôlez que les routes sensibles ou d’administration ne sont pas exposées inutilement. Une application qui protège son interface d’administration uniquement par convention, ou qui laisse filtrer des endpoints système, offre une cible facile à un attaquant.
Il faut aussi tester la résistance du chaînage des middlewares. L’ajout d’en-têtes suspects ne doit jamais permettre de contourner une règle d’accès. Ce point est prioritaire si le middleware d’authentification porte la sécurité de l’application. Le risque devient encore plus important avec les Server Actions, les rewrites personnalisés ou Turbopack, car ces composants peuvent modifier les flux de traitement attendus.
Enfin, la surveillance doit être active. Mettez en place du logging, de la corrélation d’événements de sécurité et des alertes sur les comportements inhabituels. Une tentative répétée sur un endpoint sensible, une requête contenant des en-têtes suspects ou un accès inattendu à une route protégée doivent remonter rapidement.
Mesures préventives et configuration sécurisée pour Next.js en production
La sécurité d’une application Next.js repose sur un ensemble de contrôles, pas sur une seule barrière. Les recommandations officielles insistent sur la réduction de la surface d’attaque côté navigateur et côté serveur, avec une configuration soignée des en-têtes et des règles de chargement des ressources.
Une Content Security Policy bien construite limite les vecteurs de XSS, de clickjacking et d’injection. Pour Next.js, on retrouve souvent des directives comme script-src, style-src, frame-ancestors, img-src et connect-src. L’objectif est simple, restreindre ce que le navigateur peut exécuter, charger ou intégrer.
Les autres en-têtes de sécurité doivent aussi être présents, comme X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security et Referrer-Policy. Ces réglages ne remplacent pas une authentification correcte, mais ils réduisent nettement les possibilités d’attaque côté client et côté transport.
Défense multicouche et hygiène de sécurité
Le bon réflexe consiste à activer et vérifier tous les middlewares d’authentification et d’autorisation requis, puis à compléter par une validation stricte des entrées côté serveur. Cette validation doit empêcher les injections, les paramètres inattendus et les abus d’API. Sur une application exposée, il faut aussi prévoir du rate limiting pour contenir les tentatives automatisées.
Pensez aussi à activer une double authentification pour les accès administratifs.
Les outils de veille comme npm audit et Dependabot aident à détecter les dépendances vulnérables plus tôt. Ils s’inscrivent dans une logique OWASP plus large, avec les risques de Broken Access Control, Security Misconfiguration, Injection, Auth & Session Failures, Data Integrity Failures et Logging & Monitoring. Il faut aussi protéger les échanges contre le CSRF et n’autoriser que des listes blanches de domaines lorsque certaines routes ou URLs sont exposées.
En pratique, une application robuste combine plusieurs couches de contrôle, une surveillance continue et une politique de mise à jour rapide. C’est ce niveau de discipline qui fait la différence entre une surface d’attaque maîtrisée et une exposition durable.
Synthèse des erreurs à ne pas commettre sur Next.js avant le passage en production
Les erreurs reviennent souvent au même schéma. On suppose qu’une application créée avec create-next-app est protégée par défaut, on oublie d’inventorier tous les environnements, puis on repousse la mise à jour alors qu’un correctif est déjà disponible. Ce sont précisément ces délais qui laissent le temps à une attaque de réussir.
Il ne faut pas non plus confier toute la sécurité à un seul middleware ou à une seule couche de protection. La bonne approche repose sur la défense en profondeur, avec authentification, filtrage réseau, validation serveur, en-têtes de sécurité, surveillance et audit des dépendances. Enfin, après correction, la vigilance ne doit pas retomber. Une veille active et des alertes bien réglées permettent de détecter une régression ou une nouvelle vulnérabilité avant qu’elle ne se transforme en incident.
En résumé, une application Next.js sûre est d’abord une application à jour, inventoriée, testée et surveillée avec méthode.
