Failles Next.js et React : qui est concerné par les correctifs d’octobre

Si votre site ou votre boutique fonctionne sous Next.js, d’importants correctifs de sécurité sont parus pour lui en octobre. Le 14 octobre 2026, l’équipe de Next.js a publié les versions 16.4.1 et 15.5.28, qui ferment trois failles. Deux d’entre elles peuvent permettre à un tiers d’exécuter son propre code sur le serveur sans connexion. Le même jour sont aussi sortis des correctifs de React pour les sites qui utilisent React Server Components.

Tous les sites sous Next.js ne sont pas exposés, et beaucoup de dirigeants d’entreprise ne savent même pas sur quoi repose leur site. J’explique ci-dessous qui est concerné par ces failles, comment vérifier la version sans développeur, que faire aujourd’hui et que confier au prestataire. État des connaissances : 30 octobre 2026. Les versions corrigées peuvent changer : avant la mise à jour, vérifiez-les donc sur le blog de Next.js.

Ce qui s’est passé le 14 octobre

Next.js est un framework populaire pour construire des sites et des boutiques avec React, développé par la société Vercel. Le 14 octobre, l’équipe a publié une mise à jour de sécurité en dehors du calendrier habituel. L’annonce sur le blog de Next.js décrit trois erreurs :

• Optimisation d’images et fichiers SVG (CVE-2026-96889). L’erreur se trouve dans la bibliothèque librsvg, utilisée par sharp, l’outil qui redimensionne les images sur le serveur. Sous Linux avec la bibliothèque glibc, un fichier SVG piégé peut conduire à l’exécution de code à distance. Gravité : critique.
• Fonctions « use cache » (GHSA-673q-mjm6-r5xr). Concerne uniquement Next.js 16 avec les Cache Components activés. Quand une fonction dotée de la directive use cache renvoie plusieurs tableaux typés (typed arrays), un attaquant sans connexion peut exécuter du code sur le serveur. Il n’existe pas de contournement. Gravité : critique.
• Server Actions (GHSA-p3m5-59mp-jv5r). Des requêtes piégées peuvent charger le processeur au point que le site cesse de répondre (attaque DoS). Gravité : élevée.

Les deux failles critiques ont, dans les signalements sur GitHub, une note de 9,5 sur 10 sur l’échelle CVSS 4.0. L’agence de cybersécurité de Singapour, la CSA, recommande dans son alerte du 20 octobre une mise à jour immédiate. Vercel ne mentionne pas d’attaques dans son annonce, et la faille CVE-2026-96889 ne figure pas dans le catalogue KEV de la CISA, c’est-à-dire la liste américaine des failles exploitées lors d’attaques (au 29 octobre 2026). C’est le bon moment pour corriger le site calmement, et non dans la précipitation.

Qui est concerné par ces failles

En bref : elles concernent les sites sur lesquels Next.js fonctionne sur le serveur, c’est-à-dire prépare les pages ou les images au moment où le client arrive.

Pour la faille « use cache », Next.js recommande la mise à jour même quand le projet ne contient pas de telles fonctions. Un site sous Next.js reçoit les correctifs de React avec la mise à jour de Next.js, car le framework embarque sa propre copie de ces paquets. Les projets qui utilisent React Server Components dans un autre outil, par exemple React Router ou Waku, les mettent à jour séparément.

Ce que ces failles ne concernent pas :

• les sites sous WordPress, WooCommerce, Shoper et d’autres systèmes sans Next.js,
• les applications en React seul, sans serveur (par exemple construites avec Vite) : l’équipe de React écrit en toutes lettres que le code sans serveur n’est pas exposé,
• les sites Next.js exportés en statique (output: 'export'). L’hébergement ne contient alors que des fichiers HTML, CSS et JavaScript, et l’export statique ne prend en charge ni les Server Actions ni l’optimisation d’images par défaut. Mettez tout de même ce site à jour lors de la prochaine reconstruction.

Attention aux anciennes versions. Selon la politique de support de Next.js, les lignes 14.x et plus anciennes ne reçoivent plus de mises à jour, et les correctifs d’octobre ne sont sortis que pour 15.5 et 16.4. Un site sous Next.js 14 exige le passage à une ligne plus récente. La ligne 15 doit recevoir des correctifs de sécurité jusqu’au 31 janvier 2027 : il vaut donc déjà la peine de planifier le passage à la 16.

Vercel, Netlify ou serveur propre

• Serveur propre (VPS, Docker, hébergement avec Node.js). C’est ici que le risque est le plus grand, car les images sont traitées par votre serveur, généralement sous Linux. Les systèmes répandus Debian et Ubuntu utilisent glibc.
• Netlify. Dans son annonce du 14 octobre, Netlify écrit que les images de next/image sont gérées par son propre service Image CDN : la faille SVG ne fonctionne donc pas par cette voie. La faille « use cache » concerne toutefois aussi les sites sur Netlify. Netlify recommande la mise à jour et la suppression des aperçus publics d’anciens déploiements (deploy previews), car ils peuvent rester vulnérables.
• Vercel. Je n’ai pas trouvé d’annonce de Vercel indiquant que la plateforme protège elle-même les projets contre ces failles (lors de la publication d’août, une telle annonce existait). Partez donc du principe que le projet doit être mis à jour et redéployé.

Comment vérifier si votre site est exposé

Méthode 1 : le navigateur (2 minutes)

1. Ouvrez votre site dans Chrome ou Edge sur un ordinateur.
2. Appuyez sur F12 (ou faites un clic droit et choisissez Inspecter), puis ouvrez l’onglet Console.
3. Saisissez next.version et appuyez sur Entrée.

Si un numéro apparaît, par exemple "16.4.0", le site fonctionne sous Next.js et vous connaissez sa version. La version 16.4.1 ou supérieure ou, dans la ligne 15, 15.5.28 ou supérieure signifie que les correctifs d’octobre sont en place. Comparez séparément les nombres entre les points : 15.5.3 est une version plus ancienne que 15.5.28. Si la console affiche l’erreur « next is not defined », le site n’est très probablement pas construit avec Next.js.

Cette méthode ne dit pas si le site utilise « use cache » ou des Server Actions, ni quelle version de sharp a le serveur. Le prestataire, lui, le sait.

Méthode 2 : les fichiers du projet

Si vous avez accès au dépôt (par exemple sur GitHub), ouvrez le fichier package.json et repérez la ligne avec "next". La notation ^16.4.0 désigne une plage, et la version exacte est indiquée par le fichier de verrouillage : package-lock.json, pnpm-lock.yaml ou yarn.lock. Un développeur vérifiera tout d’une seule commande :

npm ls next sharp

Méthode 3 : le panneau de l’hébergeur

Sur Vercel et Netlify, ouvrez le dernier déploiement et ses journaux de build. Au début du build, Next.js affiche une ligne avec la version, par exemple « ▲ Next.js 16.4.1 ». Vérifiez le déploiement de production, et pas seulement celui de test.

Que faire aujourd’hui

1. Déterminez si le site repose sur Next.js et dans quelle version. La méthode 1 ou une question au prestataire suffisent.
2. Faites une sauvegarde du code et des données. Je décris comment la faire correctement dans le guide sur la sauvegarde selon la règle 3-2-1.
3. Mettez à jour Next.js vers au moins 16.4.1 (ligne 16) ou 15.5.28 (ligne 15). Fin octobre, la version la plus récente était la 16.4.3 du 23 octobre.
4. Vérifiez sharp. Il doit être en version 0.35.5 ou plus récente. Next.js 15.5.28 accepte encore l’ancienne branche sharp 0.34 : après la mise à jour, assurez-vous donc de ce qui a réellement été installé.
5. Reconstruisez et redéployez le site, puis cliquez sur les endroits les plus importants : formulaire, panier, connexion, galerie d’images.
6. Planifiez la prochaine mise à jour. Pour le 3 novembre, Next.js a annoncé une publication de sécurité planifiée avec les correctifs de sept failles de gravité moyenne. Quand elle paraîtra, répétez les étapes 2 à 5.

Commandes pour la personne qui déploie le site :

npm install next@16.4.1   # ligne 16 (ou une 16.4.x plus récente)
npm install next@15.5.28  # ligne 15
npm ls sharp              # attendu : 0.35.5 ou plus récent

Si le site est en 16.0–16.3, le passage à 16.4.1 est plus qu’un petit correctif et exige un test avant le déploiement. Si cela doit prendre plus de temps, le contournement provisoire de la faille des images consiste à imposer sharp 0.35.5 ou plus récent. Pour la faille « use cache », il n’y a pas de contournement.

Que confier à l’hébergeur ou au prestataire

L’hébergeur met généralement à jour le système et Node.js, mais pas les paquets de votre application. Next.js et sharp font partie du projet : ils sont donc mis à jour par le prestataire du site ou par la personne qui a accès au code et aux déploiements. Le mieux est d’avoir consigné qui est responsable de quoi dans le contrat de réalisation du site.

Message à copier :

Bonjour, Suite à la mise à jour de sécurité de Next.js du 14 octobre 2026, je vous demande :

1. de m’indiquer sur quelle version de Next.js et de sharp tourne notre site (production, version de test et aperçus),
2. de le mettre à jour vers au moins 16.4.1 ou 15.5.28 et de confirmer la version après le déploiement,
3. de m’indiquer si le site utilise l’optimisation d’images, des Server Actions et « use cache »,
4. un plan de mise à jour après la publication de sécurité de Next.js annoncée pour le 3 novembre.

Pourriez-vous me répondre d’ici le [date] ? Merci.

Si le prestataire répond que le site « n’utilise pas de SVG », demandez des précisions. Par défaut, Next.js n’optimise pas les fichiers SVG, et certaines analyses lient le risque à l’option dangerouslyAllowSVG activée. L’annonce officielle ne restreint toutefois pas la portée de la faille de cette façon : ce n’est donc pas une raison pour repousser la mise à jour.

Next.js tourne sur Node.js : demandez donc aussi, au passage, de vérifier la version de Node.js. Je le décris dans le guide sur la faille Node2Shell (CVE-2026-111497) dans Node.js et Brotli.

Si vous n’avez plus de contact avec le prestataire, je peux reprendre le site dans le cadre de la maintenance technique. Le forfait Veille (à partir de 149 PLN HT par mois) comprend la surveillance, les sauvegardes, les mises à jour de sécurité et une réaction sous 2 jours ouvrés. Standard (à partir de 349 PLN) et Pro (à partir de 749 PLN) ajoutent des heures de travail et une réaction plus rapide, jusqu’à 4 heures avec Pro.

Comment ne pas manquer les prochains correctifs

Depuis juillet 2026, Next.js publie les correctifs de sécurité selon un programme fixe et les annonce quelques jours à l’avance. Pour les failles graves, il les publie aussi hors calendrier, comme le 14 octobre. Trois habitudes suffisent :

• Suivez les avis de sécurité de Next.js sur GitHub (Security Advisories) ou le blog de Next.js.
• Activez Dependabot dans le dépôt du projet. Il proposera lui-même la mise à jour des paquets dans lesquels des failles ont été détectées.
• Fixez avec le prestataire un délai de réaction, par exemple l’installation du correctif d’une faille critique dans les 48 heures suivant sa publication.

En résumé

Les failles d’octobre concernent les sites dans lesquels Next.js fonctionne sur le serveur : avec optimisation d’images, Server Actions ou « use cache ». Vérifiez la version dans le navigateur, demandez au prestataire la mise à jour vers 16.4.1 ou 15.5.28 (ou plus récent) avec une confirmation écrite et n’oubliez pas la publication du 3 novembre. Si vous préférez que quelqu’un le fasse à votre place, écrivez-moi : je vérifierai les versions et mettrai le site à jour, et pour un projet plus important, je réaliserai un audit de sécurité. Je construis les nouveaux sites sous Next.js dans le cadre du service Site sur mesure.