Next.js CVE-2026-75604 : RCE non authentifiée sur Windows et heap overflow AVIF — patchs d'urgence du 25 août

> En bref : Deux vulnérabilités critiques corrigées dans Next.js le 25 août 2026 permettent toutes les deux une exécution de code à distance sans authentification. CVE-2026-75604 (CVSS 9.0) est un path traversal qui ne touche que les serveurs hébergés sur un filesystem Windows — sans workaround possible. La seconde (GHSA-2xp9-vwfh-vxw4, CVSS v4 9.5) est un heap buffer overflow dans libheif, la bibliothèque C qui parse les images AVIF via sharp : une image malveillante suffit à corrompre le heap du process Node. Les versions corrigées sont 15.5.24 (Maintenance LTS) et 16.3.3 (Active LTS). Les applications déployées sur Vercel ne sont pas concernées.

Deux vecteurs distincts, un seul réflexe : mettre à niveau

CVE-2026-75604 — path traversal Windows. La faille affecte les applications qui utilisent le Pages Router ou l'App Router (sans Cache Components) quand le serveur de production tourne sur un filesystem Windows. Linux et macOS ne sont pas touchés. Les versions concernées vont de 13.4 jusqu'à 15.5.23, et de 16.0 à 16.3.2. Vercel est claire dans son advisory : il n'existe aucune solution de contournement pour les applications hébergées sur Windows, la montée de version est la seule option. La faille a été rapportée de façon responsable par les chercheurs evolutionstorm et B0RI.

Le heap overflow AVIF. Next.js optimise les images via le package sharp, qui s'appuie sur la bibliothèque C libheif pour décoder le format AVIF. Un fichier AVIF forgé, contenant des références imbriquées de type identity-derivation et auxiliary item, pousse libheif à construire une image décodée avec deux plans Alpha à des profondeurs différentes : le scaler alloue un buffer pour le premier plan (8 bits) puis y écrit des échantillons 16 bits du second — un débordement de heap d'environ 16 384 octets au-delà de la zone allouée. Les chercheurs rootxharsh et KarimPwnz (équipe Hacktron) ont publié un PoC Python complet et affirment avoir obtenu une RCE sur plusieurs applications.

Point important : l'optimisation AVIF n'est active que si votre configuration ajoute explicitement image/avif dans la clé formats de next.config.js. Sans cette ligne, la surface AVIF est fermée. Les releases corrigées vont plus loin : elles désactivent entièrement l'optimisation AVIF en attendant que le correctif amont de libheif (affecté jusqu'à 1.23.1 inclus) soit propagé — au 27 août, la version 1.23.2 n'était toujours pas publiée.

Pourquoi ça vous concerne

La fenêtre Windows est étroite dans le SaaS français (la plupart des déploiements Next.js self-hosted tournent sous Linux), mais deux points méritent attention. D'abord, la chaîne d'optimisation d'images traite par définition des fichiers fournis par vos utilisateurs — c'est une entrée non authentifiée typique, et elle repose sur du code natif C (libheif) où une corruption mémoire devient exécution de code. Ensuite, Vercel a désormais un programme de sécurité mensuel formel : c'est la deuxième release programmée, et l'entreprise a avancé la date d'un jour après avoir découvert une faille critique supplémentaire dans une dépendance amont. Le rythme des correctifs Next.js va rester soutenu — la juillet release avait déjà corrigé neuf vulnérabilités (DoS, SSRF, middleware bypass), et celles d'août s'y ajoutent même si vous étiez à jour en juillet.

Ce qu'il faut faire

La leçon plus large : le pipeline d'images est du code natif exposé

La plupart des équipes considèrent l'optimisation d'images comme une fonctionnalité de confort. Techniquement, c'est un parseur C alimenté par des entrées publiques, branché directement dans le process de votre application web. La pile sharp/libheif est saine et bien maintenue — c'est justement pour ça qu'elle est partout, et qu'une faille dedans expose des milliers d'applications d'un coup. Si votre produit accepte des fichiers de vos utilisateurs (photos de profil, justificatifs, CV), votre surface d'attaque inclut ces bibliothèques natives, avec leur historique de vulnérabilités mémoire. Un audit qui ne teste que la couche HTTP (auth, autorisation, logique métier) rate cette classe de risque : le fuzzing d'uploads et la vérification de la chaîne de traitement des fichiers en font partie.