- Une mise à jour de sécurité Next.js est annoncée pour le 30 septembre 2026 : elle corrigera neuf vulnérabilités, une critique, deux hautes, cinq moyennes et une faible (Next.js, 23 septembre 2026).
- Deux versions sont annoncées : 16.3.7 et 15.5.27. Les avis complets, avec l’impact et les versions touchées, seront publiés avec la mise à jour, pas avant.
- La vérification passe par votre prestataire : la version de Next.js d’un site ne se prouve pas depuis l’extérieur, elle se lit dans le fichier de dépendances et le fichier de verrouillage du projet.
- Sept questions suffisent pour savoir où vous en êtes. IA Agency documente la pile technique et l’inventaire des composants de chaque site livré, et vous dit lesquelles poser.
Un lundi matin, un associé vous transfère un lien : une alerte de sécurité sur Next.js. Vous ouvrez votre site, tout s’affiche, les formulaires partent, les commandes arrivent.
Rien, absolument rien, ne vous dit si l’alerte vous concerne. Next.js est le framework qui fait tourner une grande partie des sites d’entreprise récents, construit au-dessus de React, la brique qui produit l’affichage. Les failles publiées ces derniers mois ne viennent pas du texte de votre site : elles viennent de couches profondes, plusieurs étages sous ce que votre prestataire a écrit, dans des bibliothèques que personne n’a choisies une par une.
Voici ce que la mise à jour annoncée pour le 30 septembre 2026 va corriger, comment établir quelle version votre site utilise, et les sept questions à poser à votre prestataire avant l’échéance.
Quelles failles Next.js sont en jeu, et que corrige la mise à jour du 30 septembre 2026 ?
Next.js a publié dix avis de sécurité entre le 21 juillet et le 22 septembre 2026, dont trois critiques entre le 25 août et le 22 septembre 2026 (GitHub Security Advisories, dépôt vercel/next.js). Voici les plus sérieux.
| Référence de l’avis | Ce qui est touché | Criticité | Publication |
|---|---|---|---|
| GHSA-vcvr-r3jv-pc5j | Exécution de code à distance dans la génération d’images next/og | Critique | 22 septembre 2026 |
| GHSA-2xp9-vwfh-vxw4 | Exécution de code à distance non authentifiée dans l’API d’optimisation d’images, quand des fichiers AVIF sont utilisés | Critique | 25 août 2026 |
| GHSA-p293-qw3h-jr36 | Exécution de code à distance non authentifiée sur les serveurs hébergés sous Windows | Critique | 25 août 2026 |
| GHSA-p9j2-gv94-2wf4 | Falsification de requête côté serveur dans les réécritures d’URL | Haute | 21 juillet 2026 |
| GHSA-m99w-x7hq-7vfj | Déni de service dans l’App Router via les Server Actions | Haute | 21 juillet 2026 |
| GHSA-4c39-4ccg-62r3 | Charge utile de Server Action non bornée dans le runtime Edge | Moyenne | 21 juillet 2026 |
Que corrige exactement la mise à jour du 30 septembre 2026 ?
Next.js publie ses mises à jour de sécurité par lots, à date annoncée. Celle du 30 septembre 2026 a été annoncée le 23 septembre 2026 par l’éditeur : elle corrigera neuf vulnérabilités, une critique, deux hautes, cinq moyennes et une faible, et prendra la forme des versions 16.3.7 et 15.5.27.
Ce que l’annonce ne dit pas encore compte autant. Les numéros de référence de ces neuf failles ne sont pas publics : les avis complets, avec l’impact, les versions touchées et les instructions de mise à jour, seront publiés avec le correctif. Tant que la mise à jour n’est pas sortie, elle est annoncée, pas disponible, et vous ne pouvez donc pas encore savoir si votre site figure parmi les versions vulnérables.
Ce préavis existe pour une raison précise : laisser aux équipes le délai de préparer leur mise à jour. L’éditeur recommande de passer sur une version corrigée dès qu’elle est disponible. Ce que vous pouvez savoir dès aujourd’hui, en revanche, c’est quelle version votre site fait tourner.
Comment savoir quelle version de Next.js fait tourner votre site ?
La version de Next.js d’un site ne se prouve pas depuis un navigateur. Quatre chemins existent, et un seul donne une certitude. L’ordre compte : on commence par ce qui se voit de l’extérieur, on finit par la seule preuve fiable.
- Ce que votre site sert depuis /_next/static/ : les fichiers produits à la construction du site portent parfois des marqueurs liés à la version. C’est un indice, jamais une preuve, et il disparaît sur les sites servis derrière un cache.
- La réponse du serveur : certaines configurations laissent passer une mention de version dans leur réponse. Beaucoup la retirent volontairement, et son absence ne prouve rien du tout.
- Les outils publics de détection de briques techniques : ils devinent le framework d’un site à partir de signatures visibles. Ils se trompent dans les deux sens, en annonçant une version périmée sur un site à jour, et l’inverse.
- Le fichier de dépendances du projet et son fichier de verrouillage : c’est la seule réponse fiable. Le premier déclare la version demandée, le second fige la version réellement installée, celle de chaque composant tiers comprise. Seul votre prestataire peut les ouvrir.
Comment le dire à votre prestataire ?
Dites-le sans détour à qui gère votre site : un dirigeant qui croit avoir vérifié depuis l’extérieur n’a rien vérifié. Les trois premiers signaux se contentent d’alimenter une conversation, le quatrième la tranche.
C’est la première chose qu’une agence IA sérieuse pose noir sur blanc quand elle livre un site, et le premier point qu’un audit et conseil IA objective sur un site existant : ce qui tourne réellement, en version exacte, avant toute discussion sur le risque.
Quand IA Agency livre un site, la pile technique part avec lui sous forme d’un inventaire écrit : le framework et sa version exacte, les bibliothèques embarquées et leur version, et l’endroit où le fichier de verrouillage du projet est conservé. Le jour où un avis de sécurité tombe, « suis-je concerné » se tranche en ouvrant ce document, pas en lançant une enquête.
Votre version de Next.js est-elle encore suivie en sécurité ?
Next.js publie une politique de suivi qui dit, majeure par majeure, si une version reçoit encore des correctifs de sécurité. C’est une information publique, et c’est celle que votre prestataire doit citer.
| Version majeure | Date de sortie | Statut de suivi |
|---|---|---|
| 16.x | 21 octobre 2025 | Active LTS |
| 15.x | 21 octobre 2024 | Maintenance LTS |
| 14.x | 26 octobre 2023 | Non supportée |
| 13.x | 26 octobre 2022 | Non supportée |
| 12.x | 26 octobre 2021 | Non supportée |
Source : Next.js, Support Policy. Une majeure reste en Active LTS jusqu’à la sortie de la suivante : elle reçoit les nouvelles fonctions, les corrections de bogues, les améliorations de performance et les correctifs de sécurité. À la sortie d’une nouvelle majeure, la précédente passe en Maintenance LTS : seuls les correctifs de bogues critiques et les mises à jour de sécurité essentielles y sont encore livrés. Chaque majeure reste en Maintenance LTS deux ans après sa sortie initiale.
Ce que cela change pour vous tient en une phrase : un site en 14.x, 13.x ou 12.x ne recevra rien le 30 septembre 2026. Il existe une exception, et il ne faut pas bâtir une décision dessus : dans de rares cas, selon la criticité du défaut, l’éditeur corrige aussi des versions qui ne sont plus supportées. Enfin, si l’on vous parle du canal canary, sachez que ces versions sont publiées quotidiennement et ne sont pas recommandées pour du trafic de production.
« Une version de framework qui n’est plus suivie ne devient pas dangereuse le jour où une faille est publiée. Elle l’était déjà, simplement personne ne l’avait encore écrit. »
Hébergement géré ou serveur exploité par votre prestataire : qui applique réellement le correctif ?
L’hébergement d’un site Next.js change son exposition réelle, et pas seulement le confort de celui qui l’exploite. Deux vulnérabilités documentées le montrent mieux que n’importe quel principe.
CVE-2026-64644, publiée le 27 juillet 2026 par CVE.org, est un déni de service de l’API d’optimisation d’images déclenché par un fichier SVG. Elle touche les versions 15.5.0 à 15.5.20 et 16.0.0 à 16.2.10, mais uniquement dans certaines configurations auto-hébergées utilisant le chargeur d’images par défaut et le réglage remotePatterns. Les sites hébergés sur Vercel, ceux qui emploient l’option unoptimized: true et ceux qui emploient un chargeur d’images personnalisé ne sont pas concernés. Criticité moyenne, CVSS 4.0 de 6,3. Autrement dit : la même version de Next.js est vulnérable ou non selon la façon dont le site est hébergé et réglé.
Même enseignement sur CVE-2025-29927 (NVD, 21 mars 2025, CVSS 3.1 de 9,1), une faille critique qui permettait de contourner les vérifications d’accès d’une application Next.js : les sites hébergés sur Vercel en étaient automatiquement protégés, sans action de leur part.
- Ce qu’une plateforme gérée absorbe : la couche d’infrastructure qu’elle exploite elle-même, les mises à jour du système de ses machines, et parfois une faille du framework quand le correctif tient dans sa propre couche.
- Ce qu’elle n’absorbe pas : la version de Next.js que votre projet déclare. Personne ne la changera à votre place.
- Ce qu’elle n’absorbera jamais : un défaut du code métier de votre site, écrit pour vous et par personne d’autre.
- Ce qu’elle ne fera pas non plus : lire les avis de sécurité pour vous et vous prévenir que vous êtes concerné.
Ne laissez donc personne vous répondre qu’un hébergement géré vous protège de tout. La bonne question n’est pas « où est hébergé mon site », c’est « qui applique le correctif, sur quelle couche, et dans quel délai ».
Ce qu’implique l’application d’un correctif en urgence
Corriger une faille Next.js en urgence consiste à passer le projet sur une version corrective publiée par l’éditeur, puis à remettre le site en ligne. Rien d’autre ne referme la porte : sur la faille React2Shell (CVE-2025-55182, React, fin 2025), sur laquelle nous revenons plus bas, aucun contournement fiable n’existe, la mise à jour est la seule issue. Pour les failles déjà documentées, les versions correctives sont nommées dans l’avis : 15.5.24 et 16.3.3 pour la faille des serveurs Windows (CVE-2026-75604), 15.5.21 et 16.2.11 pour celle de l’optimisation d’images évoquée plus haut (CVE-2026-64644). Un correctif critique s’applique immédiatement, pas à la prochaine fenêtre de maintenance, et c’est un engagement qui se prend par écrit avant l’incident, pas pendant.
Pour en savoir plus : Comment choisir une agence IA en 2026 ? Voici les critères clés !
Qu’est-ce qu’un site produit par un outil IA change à votre exposition ?
Un site produit ou hébergé par un prestataire qui s’appuie sur des outils IA n’est pas plus fragile par nature. Ce qui change, c’est la vitesse à laquelle sa pile s’est constituée, et le nombre de briques que personne n’a examinées une par une.
Un site généré en quelques jours embarque des dizaines de bibliothèques tirées les unes par les autres. La faille ne se loge pas forcément dans le framework : elle peut vivre plusieurs étages en dessous, dans un composant dont l’auteur du site ignore l’existence. React2Shell en est l’illustration exacte : les paquets touchés s’appellent react-server-dom-webpack, react-server-dom-parcel et react-server-dom-turbopack, et aucun dirigeant n’a jamais décidé de les installer.
Que manque-t-il à un site livré sans engagement de suivi ?
La vraie question n’est donc pas « qui a écrit le code », mais « qui le maintiendra dans deux ans ». Un site livré sans engagement de suivi est un site dont personne ne lira les avis de sécurité. Voici ce qui manque, concrètement, à un site livré sans ce suivi.
- Aucun inventaire écrit des composants embarqués, donc aucun moyen de trancher « suis-je concerné » quand un avis tombe.
- Personne d’abonné aux avis de sécurité de l’éditeur, ni à ceux des composants tiers.
- Aucune version cible ni fenêtre de mise à jour convenue à l’avance, donc une négociation à chaque alerte.
- Aucun interlocuteur identifié pour appliquer un correctif un mardi soir.
C’est exactement le point où se placent une création de site internet IA et un développement no-code sérieux : livrer vite ne dispense pas de livrer l’inventaire de ce qui a été installé, ni de dire qui le tiendra à jour.
Exigez trois lignes par écrit dans votre contrat de maintenance. Qui surveille les avis de sécurité de votre framework. Sous quel délai un correctif critique est appliqué. Qui vous prévient quand votre version cesse d’être suivie. Sans ces trois lignes, la maintenance se limite à corriger ce que vous remarquez vous-même, et une faille ne se remarque pas. Nos engagements de transparence sur ce que nous installons et documentons figurent dans notre charte IA éthique et responsable.
« La question n’est pas de savoir qui a écrit le code de votre site. C’est de savoir qui lira les avis de sécurité à sa place dans deux ans. »
Quels risques concrets si personne ne met à jour, et avez-vous déjà pu être visé ?
Une exécution de code à distance non authentifiée signifie qu’un inconnu peut faire tourner son propre programme sur votre serveur, sans compte et sans mot de passe, à travers une simple requête envoyée depuis Internet. C’est la catégorie la plus lourde, et c’est celle des trois avis critiques publiés par Next.js entre le 25 août et le 22 septembre 2026.
React2Shell (CVE-2025-55182), publiée par React fin 2025, en donne la mesure : exécution de code à distance non authentifiée dans le protocole Flight des React Server Components, atteignable par une simple requête HTTP, notée CVSS 10 sur 10, le score maximum. Aucun contournement fiable n’existe, il faut mettre à jour. Les données de Wiz Research montrent que 39 % des environnements cloud contiennent des instances vulnérables, et une activité d’exploitation réelle a été détectée dès le 5 décembre 2025 (Google Cloud Threat Intelligence). Ce ne sont pas des scénarios d’école.
- Vos données et celles de vos visiteurs deviennent consultables par un attaquant qui exécute du code sur la machine.
- Votre serveur peut servir à héberger du contenu étranger ou à attaquer d’autres sites, avec votre nom de domaine dessus.
- CVE-2026-75604 (CVE.org, 1er septembre 2026, CVSS 3.1 de 9,0) peut exposer des données de construction privées et la clé du manifeste d’une application.
- Un déni de service met votre site hors ligne sans qu’aucune donnée ne sorte : le dommage est commercial, pas confidentiel.
Le risque d’exploitation en masse, et les traces à faire chercher
CVE-2025-55182, activement exploitée en conditions réelles selon Google Cloud Threat Intelligence, illustre ce qui rend une faille exploitable en masse : elle ne demande ni compte, ni mot de passe, ni la moindre connaissance de votre entreprise, seulement une requête HTTP. Une faille de ce profil se cherche à l’aveugle, sur tout ce qui répond, et rien ne distingue votre serveur d’un autre pour qui balaie Internet à la recherche de versions vulnérables. Évaluer votre propre risque tient donc à une seule question, et elle ne porte ni sur votre taille ni sur votre notoriété : quelle version votre site fait-il tourner ? Le risque est fort tant que cette version figure parmi les versions vulnérables, et c’est la seule variable sur laquelle vous pouvez agir.
Reste la question qui angoisse le plus : ai-je déjà été visé ? Vous ne pouvez pas y répondre seul, et personne ne peut y répondre de mémoire. C’est une question de journaux serveur : il faut faire chercher, dans les journaux d’accès, les requêtes suspectes sur la période qui précède le correctif, et obtenir un compte rendu écrit. La surveillance des avis de sécurité, elle, se met en place une fois pour toutes, comme n’importe quelle veille répétitive qu’un projet d’automatisation IA permet d’outiller.
À découvrir absolument : Pourquoi tant de projets d’agents IA autonomes échouent-ils avant d’atteindre la production ?
Les questions à poser à votre prestataire avant le 30 septembre 2026
Voici les sept questions à envoyer. Elles sont conçues pour être copiées telles quelles, et chacune se juge à la forme de la réponse autant qu’à son contenu.
Les sept questions, et ce que révèle chaque réponse
- Quelle version exacte de Next.js tourne sur notre site, et dans quel fichier l’avez-vous vue ? Rassurant : un numéro précis et le nom du fichier de verrouillage. Inquiétant : « la dernière », ou un numéro donné de mémoire.
- Cette version est-elle encore suivie en sécurité par l’éditeur ? Rassurant : une réponse adossée à la politique de suivi publiée par Next.js. Inquiétant : « elle marche très bien ».
- Appliquerez-vous la mise à jour du 30 septembre 2026, et sous quel délai ? Rassurant : une date, un nom, et un correctif critique appliqué immédiatement. Inquiétant : « on regardera ».
- Qui surveille les avis de sécurité de React et de Next.js pour notre site ? Rassurant : une personne nommée et une source citée. Inquiétant : personne, ou « l’hébergeur s’en occupe ».
- Avons-nous un inventaire écrit des bibliothèques embarquées par notre site ? Rassurant : un document daté, remis sur demande. Inquiétant : « c’est dans le projet ».
- Où notre site est-il hébergé, et qui applique les correctifs sur cette machine ? Rassurant : une réponse qui distingue la couche d’hébergement de l’application. Inquiétant : « tout est géré ».
- Pouvez-vous vérifier dans les journaux serveur si notre site a déjà été visé ? Rassurant : une période examinée et un compte rendu écrit. Inquiétant : « il n’y a rien eu ».
Une réponse écrite vaut plus qu’une conversation rassurante : elle date l’engagement. Si trois réponses sur sept manquent, ce n’est pas votre prestataire qui est en cause, c’est votre visibilité sur votre propre site.
Une vulnérabilité ne ralentit rien, ne casse aucun affichage et ne déclenche aucune alerte visible. Entre une version corrigée et une version vulnérable, votre site est strictement identique à l’écran, et il le restera jusqu’au jour où quelqu’un en profite. Le seul signal fiable est la version déclarée dans le projet.
Obtenez votre devis personnalisé
Pourquoi confier la sécurité de votre site à IA Agency ?
IA Agency conçoit et fait vivre des sites d’entreprise avec des outils IA, et traite la sécurité comme une partie du livrable plutôt que comme une option facturée après coup. Concrètement : un inventaire écrit des bibliothèques à la livraison, une version cible du framework notée au contrat, une surveillance des avis de sécurité de l’éditeur, et un interlocuteur qui répond quand une échéance comme celle du 30 septembre 2026 approche.
Nous intervenons aussi sur des sites que nous n’avons pas construits, et le premier travail y est toujours le même : établir ce qui tourne réellement, ce qui est encore suivi, et ce qui ne l’est plus. Si vous n’avez pas ces trois réponses aujourd’hui, contactez-nous.
Ce qu’il faut retenir avant le 30 septembre 2026
La mise à jour de sécurité Next.js annoncée pour le 30 septembre 2026 corrigera neuf vulnérabilités et prendra la forme des versions 16.3.7 et 15.5.27 (Next.js, 23 septembre 2026). Vous n’avez pas à comprendre ces failles, ni à savoir ce qu’est un framework.
Vous avez à obtenir trois réponses écrites : quelle version votre site utilise, si elle est encore suivie en sécurité, et qui appliquera le correctif le jour où il sort. Si personne ne peut vous répondre aujourd’hui, vous avez déjà la réponse la plus importante. Demandez votre audit IA.
Faut-il abandonner Next.js après ces failles de sécurité ?
Non. Next.js publie ses avis de sécurité, tient à jour un calendrier de suivi par version et corrige par lots datés : dix avis ont été publiés entre le 21 juillet et le 22 septembre 2026 (GitHub Security Advisories, dépôt vercel/next.js). Un framework qui publie ses failles est plus sûr qu’un framework silencieux. Le risque n’est pas l’outil, c’est l’absence de quelqu’un pour appliquer ses correctifs.
Comment être prévenu des prochaines alertes de sécurité Next.js ?
Trois sources suffisent, et chacune propose un abonnement. Les avis de l’éditeur paraissent sur GitHub Security Advisories, dépôt vercel/next.js. CVE.org et NVD publient les fiches complètes avec leur score CVSS. En France, le CERT-FR diffuse par courriel des bulletins d’actualité, comme CERTFR-2025-ACT-053 consacré à la vulnérabilité des React Server Components. Nommez chez votre prestataire la personne qui reçoit ces alertes : un abonnement sans destinataire ne prévient personne.
Qui publie les alertes de sécurité Next.js en dehors de la France ?
Trois acteurs, aux rôles distincts. L’éditeur publie ses propres avis sur GitHub Security Advisories, dépôt vercel/next.js. CVE.org attribue et publie les références CVE qui servent de langage commun entre outils. La base NVD publie les fiches détaillées et leurs scores CVSS. S’y ajoutent, partout dans le monde, les équipes nationales de réponse aux incidents, les CSIRT : en France, le CERT-FR tient ce rôle et relaie les alertes les plus sérieuses. Ces ressources officielles sont publiques et consultables librement.
C’est quoi React2Shell ?
React2Shell est le surnom de CVE-2025-55182, une exécution de code à distance non authentifiée dans le protocole Flight des React Server Components, publiée par React fin 2025 et notée CVSS 10 sur 10, le score maximum. Elle est atteignable par une simple requête HTTP. Côté Next.js, la référence associée est CVE-2025-66478, et aucun contournement fiable n’existe.
Quelles versions de Next.js sont touchées par la faille des serveurs Windows ?
CVE-2026-75604, publiée le 1er septembre 2026 par CVE.org, touche précisément Next.js à partir de 13.4.0 et avant 15.5.24, ainsi que les versions 16.0.0 à 16.3.2. Les versions correctives sont 15.5.24 et 16.3.3. Notée CVSS 3.1 de 9,0, elle ne concerne que les serveurs exploités sous Windows, une configuration minoritaire pour un site web.
Mon site est-il concerné par la faille des images AVIF ?
GHSA-2xp9-vwfh-vxw4, publiée le 25 août 2026 sur GitHub Security Advisories, est une exécution de code à distance non authentifiée dans l’API d’optimisation d’images de Next.js, lorsque des fichiers AVIF sont utilisés. Sa criticité est critique. Seul votre prestataire peut dire si votre site emploie cette API et sert des fichiers AVIF : cela se vérifie dans le projet, cela ne se devine pas.
Quels modules sont concernés par la faille React2Shell ?
La liste des bibliothèques touchées par CVE-2025-55182 en compte trois : react-server-dom-webpack, react-server-dom-parcel et react-server-dom-turbopack. Les versions React vulnérables sont 19.0, 19.1.0, 19.1.1 et 19.2.0, corrigées en 19.0.1, 19.1.2 et 19.2.1. Côté Next.js, toutes les versions utilisant l’App Router à partir de 15 et à partir de 16 sont à risque. Une application peut être vulnérable même sans exposer aucune React Server Function, dès lors qu’elle prend en charge les React Server Components (RSC).
CVE-2025-29927 : mon site est-il encore concerné ?
CVE-2025-29927, publiée le 21 mars 2025 sur NVD et notée CVSS 3.1 de 9,1, permettait de contourner les vérifications d’accès d’une application Next.js. Elle touchait les versions 12.x avant 12.3.5, 13.x avant 13.5.9, 14.x avant 14.2.25 et 15.x avant 15.2.3. Les sites hébergés sur Vercel en étaient automatiquement protégés. Un site mis à jour depuis n’est plus exposé.
Quel est le défaut de sécurité le plus fréquent dans les applications Next.js et React ?
L’exécution de code à distance est le défaut le plus courant parmi les avis les plus sérieux. Les trois avis critiques publiés entre le 25 août et le 22 septembre 2026 portent tous sur ce défaut : génération d’images next/og, API d’optimisation d’images avec fichiers AVIF, serveurs hébergés sous Windows (GitHub Security Advisories, dépôt vercel/next.js). Ce n’est pas une erreur d’écriture de votre site, c’est un défaut du socle sur lequel il repose.
Qu’est-ce qu’une exécution de code à distance non authentifiée ?
Une exécution de code à distance non authentifiée, abrégée RCE dans les avis de sécurité, signifie qu’un inconnu, sans compte ni mot de passe, peut faire tourner son propre programme sur votre serveur, à travers une requête envoyée depuis Internet. C’est la catégorie la plus lourde de toutes : elle équivaut à une prise de contrôle de la machine, donc de vos données et de celles de vos visiteurs.
Un site auto-hébergé est-il plus exposé qu’un site sur une plateforme gérée ?
Cela dépend de la faille. CVE-2026-64644, publiée le 27 juillet 2026 par CVE.org, ne touche que certaines configurations auto-hébergées de Next.js utilisant le chargeur d’images par défaut et le réglage remotePatterns. Les sites employant un chargeur personnalisé, l’option unoptimized: true ou l’hébergement Vercel ne sont pas concernés. Aucune forme d’hébergement ne protège de tout, et seule la configuration de votre propre serveur dit si votre installation est concernée.
Y a-t-il eu une violation de données chez Vercel ?
Aucun des dix avis de sécurité publiés sur le dépôt vercel/next.js entre le 21 juillet et le 22 septembre 2026 ne décrit une violation de données chez l’hébergeur lui-même. Ce qui est documenté porte sur le framework, pas sur la plateforme : sur CVE-2025-29927 (NVD, 21 mars 2025), les sites hébergés sur Vercel étaient au contraire automatiquement protégés.
L’annonce de la mise à jour du 30 septembre 2026 est-elle fiable ?
C’est un préavis publié le 23 septembre 2026 par l’éditeur de Next.js lui-même, et sa crédibilité tient à cela : la source est primaire et datée. Il est destiné à laisser aux équipes le délai de préparer leur mise à jour. Le préavis annonce neuf vulnérabilités corrigées, une critique, deux hautes, cinq moyennes et une faible, ainsi que les versions 16.3.7 et 15.5.27. Les avis complets seront publiés avec la mise à jour, pas avant.
Mon site WordPress est-il concerné par les failles Next.js ?
Un site WordPress classique ne fait pas tourner Next.js : ces vulnérabilités ne le concernent pas. Deux réserves tout de même. Certains sites servent une façade Next.js devant un WordPress utilisé comme réservoir de contenu, et WordPress publie ses propres avis de sécurité. La question à poser reste identique : quel framework fait tourner la partie visible de mon site ?
Que faire si votre prestataire ne répond pas avant le 30 septembre 2026 ?
Écrivez votre demande, datez-la, et nommez précisément ce que vous attendez : la version de Next.js déclarée dans le projet, son statut de suivi et la date prévue d’application du correctif. Sans réponse, faites établir ce constat par un tiers. L’inventaire se reconstitue à partir du projet, et un prestataire muet sur la sécurité est un risque en soi.
Article mis à jour le 29 septembre 2026.
Ressources et liens utiles
[2] Next.js, « Support Policy »
[3] GitHub Security Advisories, dépôt vercel/next.js
[4] CVE.org, CVE-2026-75604, 1er septembre 2026
[5] NVD, CVE-2025-29927, 21 mars 2025
[6] CERT-FR, bulletin CERTFR-2025-ACT-053, « Vulnérabilité dans React Server Components »
La version avant le diagnostic
Avant de parler de risque, on établit ce qui tourne réellement sur votre site, en version exacte, et ce qui n’est plus suivi.
Le chantier en détail →
