Le 25 août 2026, les équipes derrière Next.js, l'un des socles techniques les plus utilisés du web moderne, ont publié une mise à jour de sécurité en urgence. Deux failles jugées critiques permettaient à un attaquant de prendre le contrôle d'un serveur sans jamais avoir besoin d'un mot de passe. La release, prévue le 26, a été avancée d'un jour quand une seconde faille a été découverte. Pour un dirigeant qui n'écrit pas de code, la nouvelle a l'air lointaine. Elle ne l'est pas. Elle raconte, une fois de plus, pourquoi la sécurité d'un site web n'est pas un état acquis le jour de la livraison, mais un entretien continu.
De quoi parle-t-on, sans jargon
Un site web moderne ne tient pas sur un seul bloc. Il repose sur des couches empilées : un serveur, un framework (la charpente logicielle qui fait tourner le site, ici Next.js), des bibliothèques tierces, une base de données. Chacune de ces couches est écrite par des humains, et chacune peut contenir un défaut découvert des mois ou des années plus tard.
Les deux failles annoncées appartiennent à la catégorie la plus grave, celle que les ingénieurs appellent RCE, pour « exécution de code à distance ». En clair : un inconnu, depuis internet, peut faire exécuter ses propres instructions sur votre serveur. Copier des données, installer un rançongiciel, défigurer le site, s'en servir comme relais pour d'autres attaques. Et dans les deux cas, aucune authentification n'était nécessaire. Pas de compte à pirater, pas de mot de passe à deviner.
Le détail le plus parlant concerne la première faille. Elle se déclenche au moment où le site optimise une image au format AVIF. Autrement dit, une simple image piégée, envoyée à un site vulnérable, pouvait suffire à compromettre le serveur. Un fichier qui ressemble à une photo de produit, et la porte est ouverte.
Les deux failles en clair
| Faille | Ce qu'elle exploite | Qui est concerné | Gravité |
|---|
| Optimisation d'image AVIF |
Une image AVIF piégée traitée par le moteur d'images du site |
Tout site auto-hébergé qui optimise des images AVIF, quel que soit le système |
9,5 sur 10 |
| Traversée de chemin (CVE-2026-75604) |
Une requête forgée qui sort du dossier autorisé pour atteindre d'autres fichiers |
Serveurs sous Windows uniquement, dans une configuration précise. Linux et macOS non concernés |
9,0 sur 10 |
Les correctifs existent et sont sortis le jour même : les versions 16.3.3 et 15.5.24 de Next.js. Pour la faille AVIF, le correctif désactive purement et simplement l'optimisation AVIF le temps qu'un composant sous-jacent soit lui-même réparé. C'est une décision d'ingénierie honnête : couper la fonction dangereuse plutôt que de laisser un site exposé.
Pourquoi ce n'est pas « qu'un truc de développeurs »
Trois chiffres résument l'enjeu. Next.js est téléchargé plus de 45 millions de fois par semaine : la surface exposée est immense. Aucune des deux failles ne demandait de mot de passe : la barrière d'entrée pour un attaquant était au ras du sol. Et un code d'attaque prêt à l'emploi, ce que les ingénieurs appellent un « proof of concept », a circulé publiquement sur internet un à deux jours seulement après l'annonce.
Ce dernier point est le vrai sujet. Entre le moment où une faille est rendue publique et le moment où des outils d'attaque automatisés la ciblent, il ne se passe plus des semaines. Il se passe des heures ou des jours. Un site qui attend « le prochain rendez-vous avec le prestataire » pour appliquer un correctif n'est pas prudent, il est en sursis. La question n'est pas de savoir si votre socle technique aura un jour une faille critique, tous en ont. La question est : combien de temps s'écoulera entre la sortie du correctif et son application sur votre site.
Suis-je concerné ? La bonne façon de se poser la question
La réponse honnête pour un dirigeant : vous ne pouvez pas le savoir seul, et c'est précisément le problème. Mais vous pouvez poser trois questions simples à qui gère votre site.
1. Sur quel socle technique tourne mon site ?
WordPress, Shopify, une application sur-mesure, un framework comme Next.js. Personne dans l'entreprise ne devrait avoir à hausser les épaules devant cette question. Si personne ne connaît la réponse, c'est déjà un signal.
Dans le cas présent, les sites hébergés sur la plateforme gérée de l'éditeur (Vercel) étaient protégés automatiquement, sans aucune action à mener. Ce sont les sites auto-hébergés qui devaient appliquer le correctif à la main. C'est le cœur de la maintenance : selon l'hébergement, certaines couches sont corrigées pour vous, d'autres restent entièrement à votre charge. Encore faut-il savoir lesquelles.
3. Qui applique les correctifs, et en combien de temps ?
C'est la question qui dérange, parce que dans beaucoup d'entreprises la réponse est « personne ne s'en occupe vraiment ». Le site a été livré, il tourne, et tout le monde suppose que quelqu'un veille. Un vrai suivi de maintenance nomme un responsable, surveille les annonces de sécurité, teste le correctif sur un environnement de préproduction, puis l'applique vite. Nous détaillons ce que doit couvrir un tel contrat dans notre article sur la question « qui met à jour mon site ».
Le bon réflexe d'ingénieur
Un site web est un logiciel vivant, pas un objet figé posé une fois pour toutes. C'est le fil rouge que nous défendons dans notre dossier sur l'entretien d'un site comme un patrimoine et dans notre décryptage des mises à jour de sécurité mensuelles. L'épisode Next.js du 25 août n'est pas une exception, c'est la norme du web moderne : les éditeurs sérieux publient des correctifs à un rythme soutenu, précisément parce qu'ils cherchent activement les failles avant les attaquants.
Ce qui distingue un site protégé d'un site à risque, ce n'est donc pas la chance. C'est l'existence d'une chaîne claire : quelqu'un surveille, quelqu'un teste, quelqu'un applique, et le tout est tracé. Un site sans cette chaîne finit toujours par accumuler des correctifs non appliqués, jusqu'au jour où l'un d'eux comptait vraiment.
Ce que nous faisons chez Axiom
En tant que studio d'ingénierie web à La Réunion, nous construisons des sites et des applications en code propre et sur-mesure, et nous en assurons le suivi de sécurité dans la durée. Concrètement : veille sur les annonces de sécurité des socles que nous utilisons, application rapide des correctifs critiques après test, et surveillance continue. C'est le prolongement naturel de notre travail de conception de sites vitrines et d'applications métier : livrer un site solide, puis le garder solide.
Si vous ne savez pas sur quel socle tourne votre site, ni qui applique ses correctifs, c'est exactement le genre de point que révèle un état des lieux. Nous proposons un audit gratuit qui fait ce diagnostic, sans engagement. Et si vous préférez en parler directement, notre page contact est là pour ça.
Cet article décrit un événement de sécurité public à titre d'information. Il ne constitue ni un audit de votre installation, ni un avis de sécurité personnalisé.
