Vous gérez trois applications Next.js : un site vitrine, un portail qui produit des images de partage et un extranet. Après les avis de sécurité de septembre, faut-il traiter les trois de la même façon ? Non. La version installée donne un premier signal, mais le code exécuté, le mode de rendu et le déploiement déterminent les vérifications utiles. Voici une méthode pour passer des annonces à un plan de correction traçable, sans supposer qu'une vulnérabilité touche toute application Next.js.
Deux publications à replacer dans le bon ordre
Le 22 septembre 2026, l'équipe Next.js a publié les versions 16.3.6 et 15.5.26 après la découverte d'un problème dans des dépendances en amont de ImageResponse. Selon son avis, la possibilité d'exécution de code à distance concerne Next.js de 16.2.0 à avant 16.3.6, lorsque ImageResponse fonctionne sous Node.js dans les conditions décrites. La branche 15.x reçoit un durcissement, mais n'est pas concernée par cette exécution de code à distance. L'implémentation Edge de ImageResponse n'est pas affectée par cet avis. La fiche du registre GitHub, publiée et revue le 30 septembre pour un avis fournisseur du 22 septembre, précise une autre condition : des valeurs contrôlées par un tiers doivent parvenir au contenu, aux attributs ou aux styles SVG générés.
Le 30 septembre, une seconde publication Next.js annonce les versions 16.3.8 et 15.5.27 pour plusieurs autres problèmes. Au 1er octobre, ces versions constituent donc la cible indiquée pour les branches 16.3 et 15.5 dans cette publication. Retenir 16.3.6 comme « dernier correctif » ignorerait la suite de la chronologie. Il faut aussi consulter les avis propres à chaque défaut avant de conclure sur une autre branche ou sur une configuration précise.
Cette chronologie change la pratique : votre inventaire doit porter sur la version réellement déployée, et non uniquement sur le package.json d'un dépôt. Un verrou de dépendances modifié sans nouvelle image de production ne corrige pas le service servi aux utilisateurs.
Qualifier chaque surface avant de prioriser
Images produites et images optimisées
Une image de partage créée par ImageResponse dans next/og n'est pas la même surface que l'optimisation d'une image distante. Le premier avis vise le rendu SVG sous Node.js dans les conditions ci-dessus. Celui du 30 septembre décrit, séparément, une possibilité de requête serveur vers une destination interne à partir d'une URL distante autorisée lors de l'optimisation d'image. L'éditeur précise que l'application n'est pas concernée par ce second cas si images.remotePatterns n'est pas configuré. Sources Next.js des 22 et 30 septembre.
Pour votre portail, relevez donc les routes qui appellent ImageResponse, leur runtime et l'origine des données injectées dans le SVG. Relevez ensuite la configuration images.remotePatterns et les flux d'images distantes. Un « nous utilisons des images » ne tranche aucune de ces questions. Une route peut être concernée par une surface et pas par l'autre.
Pages, caches et métadonnées
La publication du 30 septembre décrit aussi plusieurs cas de cache et de rendu. L'un vise les applications auto-hébergées utilisant le Pages Router avec des pages générées statiquement ou régénérées progressivement. Un autre implique une page attrape-tout à la racine et des routes statiques ou régénérées. Deux cas concernent les fonctions 'use cache', dont un avec le mode brouillon, qui permet à un éditeur de prévisualiser du contenu avant publication. L'avis distingue encore une fuite de métadonnées d'images sous App Router avec webpack ; il précise que Turbopack n'est pas affecté par ce cas particulier. Enfin, le point relatif au serveur de développement next dev ne concerne pas un déploiement de production. Ces conditions sont détaillées dans l'avis Next.js du 30 septembre.
Voici un tableau de questions à renseigner, pas des verdicts sur des applications réelles :
| Application fictive | Faits à relever | Vérification prioritaire |
|---|---|---|
| Vitrine statique | Branche Next.js, hébergement, Pages ou App Router, régénération | Chercher les routes statiques ou régénérées et les configurations de cache citées dans l'avis. |
| Portail avec images dynamiques | Runtime de ImageResponse, origine des valeurs SVG, remotePatterns |
Examiner séparément la production d'images et l'optimisation d'images distantes. |
| Extranet personnalisé | Cache partagé, mode brouillon, contenu dépendant de l'utilisateur | Vérifier qu'une réponse ou une prévisualisation ne mélange pas les contextes. |
Le tableau sert à répartir le travail. Le résultat reste « à déterminer » jusqu'à la lecture du code, de la configuration et du déploiement. Un hébergement Vercel écarte le cas décrit pour le cache Pages Router auto-hébergé, selon l'éditeur ; il ne constitue pas une exemption générale pour tous les autres avis.
Mettre à jour, puis vérifier le service
Commencez par une fiche par application : dépôt et responsable, version verrouillée, version déployée, hébergeur, runtime des routes concernées, routeur, configuration des images et stratégie de cache. Ajoutez une colonne « preuve » : chemin de configuration, référence d'image de conteneur, identifiant de déploiement ou résultat d'un test inoffensif. Sans cette colonne, la matrice devient vite une liste d'hypothèses.
Préparez ensuite la mise à jour de la branche prise en charge dans une branche dédiée. Faites installer les dépendances à partir du verrou, reconstruisez l'artefact et déployez-le en préproduction. Notez la version de next dans l'artefact produit, puis celle du service après déploiement. Si votre architecture comporte plusieurs instances, vérifiez que le trafic ne passe plus par une instance ancienne. Conservez le lien entre commit, verrou, image et déploiement ; c'est ce lien qui rend le correctif auditable.
Les tests doivent suivre vos usages. Pour le portail, demandez le rendu normal d'une image avec des données de démonstration et contrôlez l'origine autorisée des images distantes. Pour la vitrine, parcourez les pages statiques et celles qui se régénèrent. Pour l'extranet, testez avec deux comptes fictifs et un brouillon : la prévisualisation doit rester dans le contexte prévu, et les pages publiques ne doivent pas exposer ce contenu. Il s'agit de tests de non-régression et de séparation des données, sans requêtes offensives ni données personnelles réelles. Une seule réponse HTTP correcte ne prouve pas qu'un cache est sûr.
Documentez enfin ce qui n'a pas pu être contrôlé : une route peu utilisée, un environnement ancien, une configuration d'hébergement inaccessible. Associez un propriétaire et une date à chaque point ouvert. La mise à jour est nécessaire, mais l'acceptation du travail repose sur le service effectivement exécuté et sur les comportements vérifiés. Pour ordonner les actions lorsque le déploiement prend du temps, le guide Partitech sur la fenêtre de correctif donne un cadre de priorisation.
Que faire aujourd'hui ?
Au 1er octobre 2026, commencez par relever vos versions déployées et les conditions précises des deux publications. Affectez ensuite chaque application à un responsable, choisissez la cible de mise à jour correspondant à sa branche et programmez les tests liés à ses surfaces réellement actives. Si un critère d'exposition reste inconnu, marquez-le comme tel et donnez-lui une vérification ; n'en déduisez ni sécurité acquise, ni exploitation certaine. Les versions et avis peuvent encore évoluer : relisez les pages de l'éditeur avant la mise en production.