Next.js vient de corriger 13 avis de sécurité. Les équipes auto-hébergées ont le plus de travail.

Le 7 mai, Vercel a publié une mise à jour de sécurité coordonnée couvrant 13 avis concernant Next.js et React Server Components. Le lot comprend des problèmes de haute sévérité liés au déni de service, à la falsification de requêtes côté serveur, à l'empoisonnement de cache et à plusieurs failles de contournement de middleware affectant App Router. Si votre équipe fait tourner Next.js en auto-hébergement sur Node, c'est vous qui avez le plus de travail à effectuer.

Les corrections arrivent dans 15.5.18 et 16.2.6. Les utilisateurs de React sur react-server-dom doivent passer à 19.0.6, 19.1.7 ou 19.2.6 selon la branche qu'ils suivent. Les versions 13.x et 14.x ne recevront aucun correctif, donc quiconque est encore sur ces versions doit planifier une mise à niveau plutôt qu'attendre un cherry-pick.

Ce que contient réellement le lot

Le CVE le plus cité par la presse est CVE-2026-23870, un DoS de haute sévérité dans la désérialisation du protocole React Flight. Une requête HTTP spécialement conçue vers n'importe quelle fonction serveur App Router peut saturer un cœur CPU. Problématique, mais il s'agit d'un type de vulnérabilité connu, qu'un WAF ou un limiteur de débit peut atténuer.

La catégorie qui mérite une lecture plus attentive est l'ensemble des contournements de middleware. Les avis décrivent des variantes où les URL .rsc et les URL de pré-chargement de segments résolvent vers la même page qu'une requête normale, mais contournent les règles du matcher middleware. En clair : si votre middleware.ts est le seul rempart entre une requête non authentifiée et une page protégée, un attaquant peut demander le même contenu via un transport différent et y accéder. Il existe une variante liée à Pages Router concernant la gestion des locales i18n, ainsi qu'un avis complémentaire pour le chemin de code Turbopack car le correctif original ne le couvrait pas.

Les avis restants couvrent le SSRF via les requêtes de mise à niveau WebSocket sur Node auto-hébergé (les applications hébergées sur Vercel ne sont pas concernées), le DoS dans l'API d'optimisation d'images, les failles XSS et l'empoisonnement de cache des réponses RSC.

Pourquoi le « middleware en tant qu'authentification » continue de faire des victimes

Lors de nos missions de test d'intrusion, c'est l'un des premiers patterns que nous testons quand Next.js est dans le périmètre. La forme se répète : un seul middleware.ts vérifie le cookie de session, redirige vers la connexion s'il est absent, et l'équipe considère toutes les routes en dessous comme protégées. Ça semble propre. Ça se lit bien dans les PR. Et il y a généralement une faille de variante de transport que quelqu'un finira par trouver.

Le middleware dans Next.js est une préoccupation de routage. Il s'exécute tôt, dispose d'API limitées et a historiquement présenté des comportements particuliers concernant la façon dont les matchers s'appliquent aux formes internes de requêtes (charges RSC, pré-chargements, segments dynamiques, chemins préfixés par locale). Chacun de ces comportements particuliers a donné naissance à une classe de CVE à un moment ou un autre. Le lot de cette semaine est le dernier rappel en date.

Quand nous construisons des applications cloud-native avec App Router, nous traitons le middleware comme un filtre de chemin rapide et plaçons les véritables contrôles d'autorisation dans le gestionnaire de route, l'action serveur ou le composant serveur lui-même. La valeur du cookie devient l'entrée, pas le verdict. Cette vérification supplémentaire ne coûte presque rien et élimine toute une famille de risques de contournement.

Que faire cette semaine

En bref :

1. Mettez à jour next vers 15.5.18 ou 16.2.6. Si vous publiez sur Pages Router avec i18n via l'adaptateur OpenNext, mettez-le également à jour vers 5.15.11.
2. Si vous dépendez directement de react-server-dom-*, alignez-vous sur la branche de correctifs 19.x que vous utilisez (19.0.6, 19.1.7 ou 19.2.6).
3. Planifiez la migration depuis 13.x ou 14.x. Ces branches ne recevront pas ces correctifs.
4. Auditez votre middleware.ts. Si une route n'est protégée que par le middleware, ajoutez un contrôle d'authentification côté serveur dans le gestionnaire de route, l'action serveur ou le layout. Ne sautez pas cette étape simplement parce que vous avez effectué la mise à jour.
5. Pour les déploiements Node auto-hébergés, examinez les journaux edge ou proxy pour détecter des requêtes .rsc inhabituelles, des mises à niveau WebSocket vers des origines inattendues et des pics de trafic vers l'API d'optimisation d'images. Les problèmes SSRF et DoS apparaîtront en priorité dans les environnements auto-hébergés.

Une note sur l'auto-hébergement vs la plateforme

Plusieurs de ces problèmes sont explicitement limités à Node auto-hébergé. Vercel indique que les projets hébergés bénéficiaient de règles WAF en amont du correctif. Netlify affirme que certains avis ne s'appliquent pas du tout à leur modèle sans serveur. Cet écart mérite réflexion lorsque vous décidez où exécuter Next.js.

À travers nos travaux de développement cloud-native, nous avons vu de nombreuses équipes choisir l'auto-hébergement pour des raisons de coût ou de conformité (notamment les clients entreprises suisses), et c'est un choix tout à fait valable. Mais vous assumez davantage de responsabilité pour la sécurité à l'exécution, et la cadence des correctifs devient une partie du budget opérationnel, pas une réflexion trimestrielle après coup.

Si le fait de maintenir une pile Next.js auto-hébergée sécurisée et à jour sur un vrai calendrier vous parle, contactez-nous. Nous réalisons ce travail sur des projets web et mobiles ainsi que des audits de sécurité, et la réponse est rarement « plus de middleware ».