Failles Next.js d'août 2026 : qui a patché à votre place

Deux exécutions de code à distance non authentifiées dans Next.js, corrigées le 25 août 2026. Réponse courte : si votre site tourne sur Vercel ou sur Netlify, vous n'avez probablement rien à faire, c'était déjà réglé avant votre réveil.

Si vous êtes sur votre propre serveur, personne n'a rien fait pour vous.

C'est cet écart qui rend la semaine intéressante, bien plus que le mot « critique ».

Au sommaire#

• Ce qui s'est passé, dans l'ordre
• Les deux failles, en langage clair
• Le vrai sujet : votre hébergeur a patché pendant la nuit
• Pourquoi il a pu le faire
• Le quart d'heure à passer si vous êtes sur votre propre serveur
• Ça va se reproduire, et plus souvent
• Les trois questions qui coûtent le plus cher
• Ce qu'il ne faut pas surjouer

Ce qui s'est passé, dans l'ordre#

La seconde faille ne venait pas de Next.js. Elle venait d'une dépendance en amont, et c'est elle qui a fait avancer la date.

Les deux failles, en langage clair#

Une image piégée qui prend la main sur le serveur#

L'origine n'est pas dans Next.js. Elle est dans libheif, la bibliothèque qui décode le format AVIF. Elle est utilisée par sharp, qui est utilisé par next/image. Trois maillons, et vous n'avez choisi aucun des trois.

Le défaut est un dépassement de tampon dans la fonction scale_nearest_neighbor(). Le code réserve une zone mémoire calculée pour des échantillons 8 bits, puis y écrit des échantillons 16 bits par un autre chemin. Sur une image de 128 par 128 pixels, cela revient à écrire 32 768 octets dans un espace de 16 384. Le reste déborde.

Aucune manipulation exotique n'est nécessaire. Il suffit que votre serveur décode l'image.

Notez le correctif : Next.js ne répare pas la faille, il coupe la fonction. C'est le bon réflexe quand le défaut est chez quelqu'un d'autre, et ça veut dire que vos images AVIF ne seront plus retaillées tant que la chaîne n'est pas à jour.

Un chemin de fichier mal filtré, uniquement sur Windows#

La seconde, CVE-2026-75604, est une traversée de répertoire. Elle demande trois conditions réunies : une application qui utilise à la fois le Pages Router et l'App Router, sans Cache Components, et un serveur sous Windows.

Le vrai sujet : votre hébergeur a patché pendant la nuit#

Voilà la partie que presque personne n'a racontée, et c'est la plus utile.

Le cas Fastly mérite l'attention : le patch existe, mais il est à passer en « Enabled » à la main dans la console. Un patch qui dort désactivé ne protège personne.

Vercel écrit noir sur blanc qu'aucune mise à jour, aucun changement de configuration et aucun redéploiement ne sont nécessaires pour les applications hébergées chez lui. Netlify dit la même chose, et recommande quand même de monter de version.

Règle d'or. Ce n'est pas votre framework qui vous a protégé, c'est votre hébergeur. Si vous n'avez pas d'hébergeur au sens où on l'entend ici, vous n'avez pas eu de protection.

Pourquoi il a pu le faire#

C'est le mécanisme, et il est nouveau. Le 13 juillet 2026, Next.js a formalisé un programme de correctifs de sécurité mensuel, avec un préavis publié avant chaque release. Le texte donne la raison à la ligne suivante : ce délai sert aussi à coordonner les hébergeurs et les partenaires, pour qu'ils déploient des règles de pare-feu qui protègent les applications pas encore mises à jour.

Le préavis du 20 août a donc offert cinq jours de tête à Vercel, Netlify, Cloudflare et Fastly.

Cinq jours dont vous n'avez pas bénéficié, parce que personne ne vous a prévenu. Sauf si vous lisez le blog Next.js le jeudi.

Le quart d'heure à passer si vous êtes sur votre propre serveur#

Un VPS, un Docker chez un client, un Coolify, un Dokploy, une machine dans un placard. Dans tous ces cas, vous êtes l'hébergeur.

npm ls next

npm install next@16.3.3   # branche 16, support actif
npm install next@15.5.24  # branche 15, maintenance

Quinze minutes par projet. Le problème n'est pas la difficulté, c'est le nombre de projets.

Ça va se reproduire, et plus souvent#

Le passage à un rythme mensuel n'est pas une lubie d'organisation. Next.js écrit la raison dans son annonce de juillet : le volume de recherche de vulnérabilités explose dans toute l'industrie, porté par la découverte assistée par modèles de langage.

Le chiffre qu'ils citent est le bon marqueur : Mozilla a divulgué 271 problèmes dans une seule release de Firefox, tous remontés par un outil d'IA. Vercel fait tourner le même genre d'outillage sur Next.js, sous le nom de deepsec, en plus de son programme de primes.

C'est une bonne nouvelle sur le fond : ces failles existaient déjà, elles sont simplement trouvées plus tôt, et par les bonnes personnes. C'est une mauvaise nouvelle pour votre agenda.

Règle d'or. La question n'est plus de savoir s'il y aura une faille. C'est de savoir combien de temps sépare la publication de l'advisory de votre npm install.

Les trois questions qui coûtent le plus cher#

Le sujet technique se règle en un quart d'heure. Le reste, non.

1. Combien de projets tournent chez vous en self-hosted, et lesquels acceptent des images déposées par des visiteurs ? Si vous ne pouvez pas répondre en trente secondes, la liste n'existe pas, et c'est le premier travail.

2. Qui reçoit l'alerte quand un advisory sort, et cette personne a-t-elle le droit de déployer un vendredi ? Une alerte qui arrive sur une boîte que personne ne lit vaut zéro. Un correctif qui attend le lundi matin aussi.

3. Un correctif de sécurité sur un projet livré il y a huit mois, c'est facturé, inclus, ou fait gratuitement à 23 h ? C'est la question dont on parle le moins, et c'est celle qui coûte le plus cher aux indépendants et aux petits ateliers.

Les trois modèles existent et se défendent. Le forfait de maintenance, où le client paie une somme fixe et vous couvrez ce genre d'événement. La facturation à l'intervention, avec un tarif écrit avant que ça arrive. Et le geste commercial, qui marche très bien jusqu'au jour où quatorze projets ont besoin du même geste le même soir.

Ce qui ne se défend pas, c'est de ne pas avoir tranché. Parce que la réponse par défaut, c'est vous à 23 h, gratuitement.

Nos réponses, puisqu'on pose les questions#

Poser ces trois questions sans y répondre serait un peu facile.

Tous nos projets livrés tournent sur Vercel ou sur Netlify. Le 25 août, on n'a eu strictement rien à faire. Ce n'est pas du mérite, c'est un choix d'hébergement fait en amont, et il vient de se rembourser tout seul. Le revers existe et vous le connaissez : vous dépendez d'une plateforme et de sa grille tarifaire.

Le premier mois après la livraison est inclus, correctifs de sécurité compris. Ensuite, c'est un forfait mensuel de 50 à 200 € selon le projet, davantage si l'application est grosse et demande un vrai suivi. Le prix est écrit dans le devis, avant de commencer.

Sur une faille critique, l'engagement est de 24 heures, week-end compris. Pas 48 h ouvrées, pas « dès que possible ». Une faille publiée un samedi se corrige le samedi.

La veille passe par les alertes GitHub sur les dépôts et par la lecture des annonces à la source. C'est ce qui a permis de voir passer le préavis du 20 août. Ce n'est pas un système parfait, et on est en train de le renforcer, sinon cet article n'existerait pas.

Et le refus habituel : si vous avez un développeur en interne, un forfait chez nous ne sert à rien. Il fera ce npm install mieux et plus vite, parce qu'il vit dans votre code toute la semaine.

Ce qu'il ne faut pas surjouer#

Deux précisions, parce que le sujet se prête à l'emballement.

Au moment des publications, aucune exploitation dans la nature n'était confirmée, et aucune démonstration publique ne circulait côté Next.js. L'advisory libheif, lui, contient de quoi reproduire le défaut, ce qui est une raison de plus de monter de version rapidement, pas une raison de paniquer.

Et méfiez-vous des chiffres d'exposition que vous verrez passer. Les millions de téléchargements hebdomadaires d'un paquet npm mesurent la popularité du paquet, pas le nombre d'applications vulnérables. Ce n'est pas un décompte de victimes.

Ce qu'on en retient#

Si vous êtes chez un grand hébergeur, cette semaine ne vous a rien coûté, et c'est une raison valable de rester chez lui. Si vous êtes sur votre propre serveur, vous venez de découvrir le prix réel de cette indépendance, et il se paie en quarts d'heure, pas en euros.

Aucune des deux positions n'est la mauvaise. La mauvaise position, c'est de croire qu'on est dans la première quand on est dans la seconde.

Questions fréquentes#

Sur le même thème#

• Next.js 16.3 : ce qui change vraiment pour votre site
• Au-delà du no-code : quand Zapier et Make ne suffisent plus
• Deux devis, 40 % d'écart : comment comparer