← Retour au blog

Faille Next.js AVIF : exécution de code à distance sans authentification

Une vulnérabilité critique dans libheif expose l'API d'optimisation d'images de Next.js à une exécution de code à distance lors du traitement d'un fichier AVIF piégé.

Illustration d'une veille de sécurité sur une faille critique affectant l'optimisation d'images AVIF dans Next.js

Dans le cadre de notre veille sécurité, nous signalons une vulnérabilité critique dans l’API d’optimisation d’images de Next.js.

Le scénario est direct: lorsqu’une application vulnérable optimise une image AVIF spécialement conçue, un défaut de mémoire dans la bibliothèque libheif peut conduire à une exécution de code à distance sans authentification.

Vercel classe l’alerte GHSA-2xp9-vwfh-vxw4 au niveau critique, avec un score CVSS v4 de 9,5/10. Les versions corrigées sont Next.js 15.5.24 et Next.js 16.3.3.

Cette faille mérite une vérification rapide sur les applications Next.js exposées, même si l’optimisation AVIF n’est pas activée par défaut.

Une faille située dans la chaîne de traitement des images

Le défaut ne se trouve pas directement dans le code de Next.js. Il apparaît dans la chaîne de dépendances utilisée pour optimiser les images:

  1. Next.js reçoit une demande d’optimisation d’image;
  2. le framework confie le traitement à Sharp;
  3. Sharp s’appuie sur libvips et libheif pour décoder certains formats, dont AVIF;
  4. une image piégée déclenche un débordement de mémoire dans libheif;
  5. ce débordement peut être exploité pour exécuter du code dans le contexte du processus applicatif.

Le bulletin libheif précise que toute application appelant heif_decode_image() avec une version vulnérable est potentiellement concernée. Next.js constitue donc un cas d’exposition important, mais la bibliothèque native reste la source du défaut.

Comment une image AVIF provoque le débordement mémoire

Une image AVIF peut contenir plusieurs éléments et plans auxiliaires, notamment pour représenter la transparence.

Le fichier malveillant décrit par les chercheurs crée une structure imbriquée qui conduit libheif à manipuler deux plans Alpha de profondeurs différentes. La bibliothèque alloue le tampon de destination à partir du premier plan, encodé sur 8 bits, puis traite un second plan sur 10 ou 12 bits comme s’il pouvait tenir dans cette même zone mémoire.

Le résultat est une écriture hors limites dans le tas, ou heap buffer overflow. Dans le scénario documenté, environ 16 Ko peuvent être écrits au-delà de la zone allouée, avec des valeurs contrôlées par l’attaquant.

Ce niveau de contrôle explique la sévérité de l’alerte. Les mainteneurs de libheif indiquent avoir obtenu une exécution de code à distance sur plusieurs applications à partir de ce défaut.

Il ne s’agit donc pas seulement d’une image susceptible de faire planter le processus. Une exploitation réussie peut permettre à l’attaquant d’exécuter ses propres instructions avec les droits du service Next.js.

Quelles versions de Next.js sont affectées ?

Le bulletin de Vercel indique les plages suivantes:

BrancheVersions affectéesVersion corrigée
Next.js 10 à 1510.0.0 à 15.5.2315.5.24
Next.js 16versions antérieures à 16.3.316.3.3

La bibliothèque libheif 1.23.1 et les versions antérieures sont vulnérables. Le correctif est intégré à libheif 1.23.2.

Au moment de la publication de cet article, aucun identifiant CVE n’est indiqué dans les bulletins officiels. Les références à suivre sont GHSA-2xp9-vwfh-vxw4 pour Next.js et GHSA-g89c-p67h-r497 pour libheif.

Dans quelles conditions une application Next.js est-elle exposée ?

La présence de Next.js ne suffit pas, à elle seule, à rendre une application exploitable. Il faut que le chemin vulnérable soit réellement utilisé.

L’exposition doit être considérée comme sérieuse lorsque plusieurs conditions sont réunies:

  • l’application exécute une version affectée de Next.js;
  • l’optimisation AVIF est activée dans la configuration des images;
  • un attaquant peut faire traiter une image AVIF qu’il contrôle;
  • le pipeline utilise une version vulnérable de libheif;
  • l’API d’optimisation d’images est accessible depuis Internet.

Dans Next.js, AVIF peut notamment être activé avec une configuration de ce type:

const nextConfig = {
  images: {
    formats: ['image/avif', 'image/webp'],
  },
}

Il faut aussi examiner les sources d’images distantes autorisées, les fonctions d’import ou d’upload, les contenus fournis par des utilisateurs et les URL transmises au composant d’image.

Une liste de domaines trop large ou un flux d’import insuffisamment contrôlé peut transformer l’optimiseur en point d’entrée vers une bibliothèque native vulnérable.

Vérifier rapidement une application Next.js

La première étape consiste à relever la version réellement installée dans l’environnement de production, pas seulement celle attendue dans package.json.

Dans un projet déployé avec Docker Compose:

docker compose exec <service> npm ls next sharp

Il faut ensuite rechercher l’activation d’AVIF dans les fichiers de configuration Next.js:

grep -R "image/avif" next.config.*

Enfin, contrôlez les éléments suivants:

  • les versions résolues dans le fichier de verrouillage;
  • la présence éventuelle de plusieurs versions de Sharp;
  • la version réellement embarquée dans l’image de production;
  • les règles remotePatterns et domains de la configuration des images;
  • les fonctionnalités qui acceptent une image ou une URL fournie par un utilisateur;
  • l’exposition effective de la route d’optimisation d’images.

Cette distinction est importante. Une dépendance corrigée dans le dépôt ne protège pas un conteneur qui n’a pas été reconstruit et redéployé.

Ce qu’il faut faire maintenant

La remédiation prioritaire consiste à mettre à jour Next.js vers une version corrigée:

  • 15.5.24 ou version ultérieure pour la branche 15;
  • 16.3.3 ou version ultérieure pour la branche 16.

Après la mise à jour:

  1. régénérez le fichier de verrouillage avec le gestionnaire de paquets utilisé par le projet;
  2. reconstruisez entièrement l’image de déploiement;
  3. vérifiez les versions de Next.js, Sharp et libheif dans le conteneur final;
  4. testez les transformations d’images réellement utilisées;
  5. redéployez le service;
  6. contrôlez les journaux et les redémarrages anormaux du processus.

La vérification de libheif 1.23.2 ou ultérieure apporte un contrôle supplémentaire utile. Selon le système et la façon dont Sharp est installé, cette bibliothèque peut être embarquée dans un paquet précompilé ou fournie par l’environnement.

Mesures temporaires si le patch doit attendre

Si la mise à jour ne peut pas être appliquée immédiatement, il faut retirer AVIF du chemin de traitement.

Les mesures compensatoires possibles sont:

  • supprimer image/avif de images.formats;
  • refuser temporairement les fichiers AVIF dans les imports et uploads;
  • empêcher l’optimiseur de récupérer des images depuis des sources non strictement autorisées;
  • désactiver la route d’optimisation ou utiliser temporairement des images non optimisées si l’architecture le permet;
  • limiter les droits et les ressources du conteneur qui exécute l’application.

Ces mesures réduisent l’exposition, mais elles ne remplacent pas le correctif. Une bibliothèque vulnérable peut être appelée par un autre composant ou réactivée lors d’une évolution de configuration.

Pourquoi il faut vérifier la dépendance native, pas seulement Next.js

Cette alerte illustre une réalité fréquente: la surface d’attaque d’une application dépasse son framework principal.

Une route web apparemment banale peut déclencher une chaîne complexe de traitements dans des bibliothèques natives. Ces composants manipulent des formats riches, des tailles contrôlées par l’entrée et des allocations mémoire. Une erreur à ce niveau peut avoir un impact bien plus important qu’une simple anomalie d’affichage.

Pour une équipe d’exploitation, la bonne réponse ne consiste donc pas uniquement à comparer un numéro de version Next.js. Il faut suivre toute la chaîne:

  • fonctionnalité exposée;
  • entrée contrôlable par un tiers;
  • dépendances JavaScript réellement résolues;
  • bibliothèques natives embarquées;
  • image ou serveur réellement déployé;
  • validation après reconstruction.

Conclusion

La faille GHSA-2xp9-vwfh-vxw4 permet à une image AVIF piégée d’atteindre un défaut critique de libheif à travers le pipeline d’optimisation de Next.js.

Le bon ordre d’action est clair:

  • identifier les applications Next.js concernées;
  • vérifier si l’optimisation AVIF est activée et atteignable;
  • mettre à jour vers Next.js 15.5.24 ou 16.3.3 au minimum;
  • confirmer la présence de libheif 1.23.2 ou ultérieure;
  • reconstruire les conteneurs et tester le traitement d’images;
  • surveiller le service après déploiement.

Ce type d’alerte fait partie du maintien en condition de sécurité: veille, qualification de l’exposition, patch, reconstruction et contrôle post-intervention.

Si vous avez besoin d’aide pour qualifier une application exposée ou organiser sa remédiation, nous pouvons intervenir dans le cadre de notre offre d’infogérance.

Sources

FAQ: faille Next.js AVIF

Quelle est la faille AVIF qui affecte Next.js ?

Une image AVIF spécialement conçue peut provoquer un débordement de mémoire dans libheif lorsque Next.js la transmet à Sharp pour optimisation. Le bulletin de Vercel indique que ce défaut peut conduire à une exécution de code à distance sans authentification.

Quelles versions de Next.js sont vulnérables ?

Le bulletin de Vercel indique que les versions Next.js 10.0.0 à 15.5.23 sont affectées, ainsi que les versions 16 antérieures à 16.3.3.

Quelles versions corrigent la faille Next.js AVIF ?

Les correctifs sont disponibles dans Next.js 15.5.24 et 16.3.3. Pour libheif, la vulnérabilité est corrigée à partir de la version 1.23.2.

L’optimisation AVIF est-elle activée par défaut dans Next.js ?

Non. Next.js utilise WebP par défaut. Le format AVIF doit normalement avoir été ajouté à la configuration images.formats, mais il faut vérifier la configuration réellement déployée et les dépendances embarquées.

Que faire si la mise à jour de Next.js ne peut pas être appliquée immédiatement ?

Il faut désactiver l’optimisation AVIF, empêcher les fichiers AVIF non fiables d’atteindre le pipeline d’images et restreindre les sources distantes autorisées, puis planifier la mise à jour sans délai.

Suivre nos publications

Retrouvez plus facilement nos analyses dans Google

Ajoutez Forget About IT à vos sources préférées pour signaler à Google que vous souhaitez voir davantage nos contenus.

Ajouter ce site à mes sources préférées sur Google Cela augmente vos chances de voir nos articles mis en avant dans le Mode IA, les Aperçus IA et la section « À la une » de Google.

Articles recommandés