L’essentiel
HEIF Heist est un ensemble de corruptions mémoire dans libheif et libde265 – les décodeurs natifs C/C++ des images HEIF, HEIC et AVIF – qui permettent à une seule image piégée de déclencher une exécution de code à distance ou, au minimum, une fuite de mémoire. Comme ces bibliothèques se trouvent sous ImageMagick, libvips et Sharp, la faille a atteint Slack, Meta, GitHub Enterprise (CVE-2026-19118), Discourse et Next.js. Elle a été rendue publique le 18 septembre 2026.
Le point gênant pour les équipes de développement : presque personne ne déclare libheif dans ses dépendances. La bibliothèque arrive de façon transitive, s’exécute sur chaque photo reçue et fait tourner du code natif en dessous des garanties mémoire de votre langage applicatif. Si votre produit accepte des images – une photo de profil, une pièce jointe de ticket de support, un AVIF servi par une chaîne d’images Next.js –, vous avez hérité de cette surface d’attaque sans l’avoir choisie. Le correctif existe (libheif v1.23.2 et la dernière libde265), mais le vrai travail consiste à retrouver chaque copie que vous livrez.
Qu’a révélé Hacktron ?
Le 18 septembre 2026, la société de recherche en sécurité Hacktron a publié HEIF Heist, fruit d’une enquête de plusieurs mois sur la façon dont les applications modernes décodent les images. L’équipe – Harsh Jaiswal, Mohan SRK, Rahul Maini et Sudhanshu Rajbhar – y fait un clin d’œil à une célèbre bande dessinée xkcd : une immense pile de logiciels reposant sur un petit composant obscur que presque personne ne maintient. Ici, ce composant, c’est libheif (avec son décodeur HEVC libde265), la bibliothèque de référence pour lire les formats HEIF, HEIC et AVIF que produisent désormais par défaut smartphones et navigateurs.
Le défaut central est un bug bas niveau classique : lors du traitement d’une image en grille, un seul calcul sur la largeur ou la hauteur provoque un dépassement d’entier, ce qui alloue un tampon trop petit dans lequel le décodeur écrit au-delà de la limite – un débordement de tampon dans le tas. Les chercheurs en ont tiré des exploits fonctionnels, tout en soulignant qu’une exécution de code complète n’est même pas nécessaire pour nuire. Selon Hacktron, même quand la RCE n’est pas immédiatement atteignable, les primitives d’attaque peuvent permettre la divulgation arbitraire du tas : un attaquant peut lire la mémoire voisine, qui peut contenir des jetons, des clés ou les données d’autres utilisateurs.
C’est la liste des cibles qui a donné tout son poids à la publication. Hacktron a démontré une exécution de code à distance sur Slack, dans les produits phares de Meta via l’envoi d’images, une RCE authentifiée sur GitHub Enterprise suivie sous CVE-2026-19118, une RCE authentifiée dans Discourse et une RCE sans authentification dans Next.js via sa fonction AVIF Image Optimization. L’équipe a aussi enchaîné la faille d’image avec une faiblesse d’authentification unique pour compromettre des comptes d’employés d’OpenAI et accéder à des dépôts de code internes – une opération qui, selon elle, a pris moins de 72 heures. Les correctifs sont livrés dans libheif v1.23.2 et la dernière libde265, accompagnés de patchs spécifiques des éditeurs concernés.
Pourquoi une bibliothèque d’images est-elle partout ?
Si HEIF Heist touche autant de produits sans lien entre eux, c’est à cause de la forme du graphe de dépendances moderne. Presque aucune application ne parle directement à libheif. Les équipes utilisent des outils d’images de haut niveau – ImageMagick pour la conversion, libvips pour des vignettes rapides, Sharp pour les chaînes Node.js – et ces outils embarquent ou lient discrètement libheif et libde265 pour prendre en charge les formats récents. Le décodeur natif s’exécute plusieurs couches sous le code réellement écrit par le développeur, et généralement sous le langage dont il comptait sur la sûreté mémoire.
C’est pourquoi un audit de paquets classique passe à côté. Un lockfile JavaScript ou Python affiche fièrement « sharp » ou « imagemagick », mais pas la bibliothèque C qui fait l’analyse risquée en dessous. Le code vulnérable est bien réel, il est atteignable depuis n’importe quel point d’entrée acceptant une image, et il reste pourtant invisible pour les outils de dépendances auxquels la plupart des équipes se fient. C’est le même angle mort des dépendances natives transitives qui a déjà frappé le secteur avec libwebp et libxml2 : un seul analyseur obscur sous une montagne d’applications.
Conséquence pratique : sécuriser cela exige de la visibilité sur votre build, pas seulement sur votre code source. Les équipes qui génèrent déjà une SBOM (nomenclature logicielle) et analysent leurs dépendances natives dans leur chaîne cloud et DevOps répondent en quelques minutes à la question « où livrons-nous libheif, et dans quelle version ? ». Les autres en sont réduites à deviner lesquels de leurs services décodent l’image d’un attaquant avec du code vulnérable – précisément la question qu’imposera un délai de réponse à incident de 24 heures.
Qu’est-ce que cela change pour les équipes en France ?
Première leçon : l’envoi d’images est une frontière d’exécution de code, pas une simple fonction de stockage. Partout où un utilisateur, un partenaire ou une intégration automatisée peut transmettre une image à votre backend – avatars, scans de pièces d’identité pour le KYC, pièces jointes de messagerie, photos produits, chaînes e-mail vers ticket –, des octets contrôlés par un attaquant atteignent un analyseur natif. Cela change la conception de la fonctionnalité : les images doivent être décodées dans un contexte isolé, aux privilèges minimaux, et non dans le processus qui détient les identifiants de votre base de données.
Deuxième leçon : la vitesse d’exploitation. Quand les assistants IA ramènent le développement d’un exploit à quelques jours, l’idée qu’un bug mémoire reste « théorique » tant que personne n’y a consacré un mois ne tient plus. Pour les secteurs régulés, cela s’ajoute à des obligations existantes : avec les obligations de signalement du Cyber Resilience Act, applicables depuis le 11 septembre 2026, et la règle des 72 heures du RGPD, une faille dont l’exploitation est confirmée dans un produit vendu dans l’UE déclenche un compte à rebours réglementaire serré.
Troisième leçon : c’est un problème de chaîne d’approvisionnement qui ne se gère qu’avec un inventaire. On ne corrige pas ce qu’on ne voit pas, et libheif est exactement le type de composant qui se cache. Que vous développiez en interne ou avec une équipe partenaire pour livrer un logiciel sur mesure, la solution durable est un processus qui recense en continu les dépendances natives dans chaque conteneur et chaque artefact de build, afin que la prochaine divulgation de ce type se règle par un correctif le jour même, et non par une chasse au trésor d’une semaine.
Que faire maintenant ?
- Mettre à jour les décodeurs partout. Passez à libheif v1.23.2 ou ultérieure et à la dernière libde265 – pas seulement dans les paquets système, mais aussi dans chaque copie embarquée ou conteneurisée d’ImageMagick, libvips ou Sharp. Reconstruisez les images et redéployez : un paquet corrigé sur l’hôte ne protège pas un conteneur qui embarque sa propre copie.
- Appliquer les avis des éditeurs. Si vous exploitez GitHub Enterprise, Discourse ou des applications auto-hébergées utilisant l’optimisation d’images de Next.js, installez les versions corrigées indiquées dans chaque avis. Le chemin Next.js ne demande aucune authentification : traitez en priorité les instances exposées sur Internet.
- Recenser les points de décodage. Listez chaque point d’entrée et chaque tâche de fond qui lit des images HEIF, HEIC ou AVIF, et générez une SBOM qui fait apparaître les bibliothèques natives, pas seulement les paquets du langage. Vous devez savoir quels services sont atteignables avec une image fournie par un attaquant.
- Désactiver ce qui est inutile. Si un service n’a jamais besoin d’accepter du HEIF ou de l’AVIF, coupez ce décodage pour les fichiers reçus. Restreindre les formats d’entrée réduit immédiatement la surface d’attaque, avant même l’arrivée d’un correctif.
- Isoler le traitement d’images. Décodez dans un bac à sable durci, éphémère et aux privilèges minimaux – processus, conteneur ou worker séparé, sans secrets ni accès réseau –, pour qu’un plantage du décodeur reste confiné au lieu de devenir une exécution de code dans votre application principale.
Questions fréquentes
Qu’est-ce que HEIF Heist ?
HEIF Heist est le nom donné par la société de sécurité Hacktron à une classe de corruptions mémoire dans les décodeurs d’images natifs libheif et libde265, qui lisent les images HEIF, HEIC et AVIF. Une image piégée peut déclencher un dépassement d’entier menant à un débordement de tampon dans le tas, avec à la clé une exécution de code à distance ou, au minimum, la divulgation arbitraire de mémoire. La faille a été rendue publique le 18 septembre 2026.
Quels produits sont touchés ?
Hacktron a démontré des chemins d’attaque contre Slack, les produits phares de Meta (via l’envoi d’images), GitHub Enterprise (RCE authentifiée, CVE-2026-19118), Discourse et Next.js (RCE sans authentification via AVIF Image Optimization). Un exploit en chaîne, combinant la faille d’image et une faiblesse du SSO d’OpenAI, a atteint des dépôts de code internes d’OpenAI. La liste n’est pas exhaustive : tout service qui décode des images HEIF, HEIC ou AVIF non fiables peut être exposé.
Pourquoi une seule bibliothèque touche-t-elle autant d’applications ?
libheif et libde265 sont des décodeurs C/C++ de bas niveau, situés sous des outils très répandus comme ImageMagick, libvips et Sharp, qui génèrent vignettes, redimensionnements et optimisations d’images dans d’innombrables backends web et mobiles. Presque aucune équipe ne déclare libheif dans son fichier de dépendances : la surface d’attaque reste invisible dans un audit de paquets classique, alors qu’elle s’exécute sur chaque image reçue.
Comment corriger et atténuer HEIF Heist ?
Passez à libheif v1.23.2 ou ultérieure et à la dernière version de libde265, y compris dans les copies embarquées ou conteneurisées d’ImageMagick, libvips et Sharp. Appliquez les avis de sécurité de Next.js, GitHub Enterprise et Discourse. Là où le décodage HEIF et AVIF n’est pas nécessaire, désactivez-le pour les fichiers envoyés par les utilisateurs, et isolez le traitement d’images dans un bac à sable durci et éphémère, pour qu’un plantage du décodeur ne devienne pas une exécution de code dans le service principal.
Quelles obligations de notification en France ?
Si la faille est effectivement exploitée et que des données personnelles sont concernées, le RGPD impose de notifier la violation à la CNIL dans les 72 heures. Les entités couvertes par NIS2 doivent en outre adresser une alerte précoce sous 24 heures en cas d’incident important. Les fabricants de produits comportant des éléments numériques vendus dans l’UE sont par ailleurs soumis, depuis le 11 septembre 2026, aux obligations de signalement du Cyber Resilience Act pour les vulnérabilités activement exploitées.
Sources
HEIF Heist — publication de Hacktron
CyberScoop — Researchers use AI to find widespread software decoder flaw
Tom’s Hardware — Hackers breach OpenAI using Claude tools via image-parser flaw