Un fuzzer IA prêt à l'emploi trouve sept failles dans FatFs, embarqué dans des millions d'appareils

De quoi s’agit-il ?

Le 1er juillet 2026, la société de sécurité runZero a divulgué sept vulnérabilités dans FatFs, une petite bibliothèque C qui permet aux appareils embarqués de lire et écrire les formats FAT et exFAT utilisés par les clés USB et cartes SD. FatFs n’a rien de confidentiel : elle est intégrée au firmware des caméras de sécurité, des drones, des automates industriels, des portefeuilles matériels de cryptomonnaies et d’innombrables autres systèmes temps réel. Sur les appareils les plus touchés, un volume de stockage ou une image firmware piégés peuvent corrompre la mémoire et exécuter du code attaquant — et comme beaucoup de puces embarquées n’ont pas les protections mémoire des smartphones et des PC, runZero résume l’impact sans détour : « tout accès physique conduit à un jailbreak ».

Les bugs eux-mêmes sont des erreurs classiques de sûreté mémoire. Ce qui rend cette divulgation intéressante, c’est la manière dont ils ont été trouvés. runZero avait déjà audité FatFs à la main en 2017 sans presque rien signaler. En revenant en mars 2026, l’équipe a pointé vers le même code un dispositif quasi entièrement prêt à l’emploi — Visual Studio Code, GitHub Copilot en mode « auto » et quelques prompts simples — et a laissé le modèle construire un fuzzer. Ce harnais a fait remonter des bugs que l’audit humain avait manqués, et a aidé à confirmer qu’ils étaient atteignables.

Comment ça marche

Un fuzzer est un outil qui injecte des données malformées dans un programme jusqu’à ce que quelque chose casse. En écrire un bon pour un parseur de système de fichiers demande normalement un vrai travail : il faut comprendre les structures sur disque, générer des images disque mutées, et câbler un harnais capable de les monter et de capturer les plantages. Ici, le LLM a produit cette tuyauterie à partir de prompts en langage naturel, et le fuzzer obtenu a exploré le code de parsing plus complètement qu’une relecture manuelle ponctuelle.

Chacune des sept trouvailles suit le même schéma. L’appareil tente de lire un volume de stockage ou une image de mise à jour délibérément corrompus, et FatFs traite mal les données. Le problème vedette est un dépassement d’entier dans le code qui monte un volume FAT32 : une arithmétique erronée produit une fausse taille de fichier, que le code ultérieur prend pour une vraie longueur de lecture — sur du matériel réel, cela peut devenir une corruption mémoire et une exécution de code. Les autres incluent un champ d’étiquette de volume exFAT qui déborde un petit tampon, des noms de fichiers longs qui débordent le code d’enrobage que beaucoup de projets placent autour de FatFs, un débordement de calcul dans la gestion du cache qui corrompt silencieusement les données sur les volumes fragmentés, une division par zéro exFAT qui peut « briquer » le matériel pendant une mise à jour, et une lecture au-delà de la fin qui laisse fuir des octets résiduels de fichiers précédemment supprimés. runZero a classé l’ensemble de CVSS Moyen à Élevé, sans aucun Critique, et a publié des images disque de démonstration ainsi qu’un harnais de test basé sur QEMU dans un dépôt public d’accompagnement, pour que les éditeurs puissent reproduire et vérifier les correctifs.

runZero est explicite : ce n’est pas un coup isolé. Le même schéma se dessine depuis plus d’un an : l’agent Big Sleep de Google a trouvé fin 2024 un bug mémoire réel et exploitable dans SQLite que le fuzzing classique avait manqué, et en juin 2026 un agent autonome a fait remonter 21 bugs de sûreté mémoire dans FFmpeg, une autre bibliothèque C très largement embarquée. Le message de l’équipe : si un pipeline IA quasiment prêt à l’emploi peut trouver ces failles, n’importe qui le peut.

Pourquoi c’est important

Deux choses ont changé ici, et une seule concerne le code. La première, c’est l’économie de la découverte. Auditer un parseur C vieux de plusieurs décennies exigeait le temps et la patience d’un spécialiste ; désormais, un développeur muni d’un assistant de code grand public peut monter un harnais de fuzzing efficace en un après-midi. Cela abaisse la barre pour les défenseurs — et tout autant pour les attaquants, qui n’ont plus besoin d’une expertise pointue en systèmes de fichiers pour partir à la recherche du prochain FatFs.

La seconde, c’est le circuit de divulgation, qui n’a pas suivi. FatFs est maintenu par un seul développeur, et runZero indique avoir tenté à plusieurs reprises de le contacter et avoir sollicité le centre de coordination JPCERT/CC du Japon, sans réponse. Résultat : il n’existe aucun correctif amont pour les bugs de corruption mémoire, aucune liste de diffusion de sécurité, et aucun canal pour prévenir les nombreux produits qui embarquent FatFs qu’ils sont exposés. Un seul des sept — un déni de service par table de partition malformée — est corrigé en amont, dans la version R0.16. Tout le reste incombe aux éditeurs en aval, à charge pour eux de corriger. runZero cite des plateformes affectées comme Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT et l’outil de mise à jour SWUpdate — ce qui propage le problème dans l’IoT grand public, les équipements industriels, les drones et les portefeuilles matériels. Le précédent cité par runZero est PixieFail, un lot de failles firmware de 2024 que les éditeurs ont mis du temps à corriger ; FatFs a la même forme et un circuit de correctif plus faible, faute d’amont réactif. À la date de la divulgation, aucune attaque n’avait été signalée.

Défenses

La leçon inconfortable, c’est que « personne ne s’est donné la peine de chercher » n’est plus une défense, parce que chercher est devenu bon marché. Constructeurs comme exploitants disposent de leviers concrets.

Si vous livrez du firmware qui touche des supports FAT ou exFAT, localisez la copie de FatFs dans votre produit et traitez-la comme un parseur non fiable manipulant des entrées contrôlées par l’attaquant. Auditez le code d’enrobage qui l’entoure — les schémas du type strcpy vers un tampon fixe sont précisément là où plusieurs de ces bugs se logent — et examinez de près la façon dont vous calculez noms et tailles de fichiers. Récupérez la version amont R0.16 pour le correctif de table de partition, et rétroportez ou atténuez vous-même les problèmes de corruption mémoire, puisqu’aucun correctif amont n’existe. Là où le matériel le permet, activez les protections mémoire (régions MPU/MMU, canaris de pile, W^X) pour qu’un bug de parsing se traduise par un plantage plutôt que par un jailbreak. Envisagez de lancer votre propre passe de fuzzing assistée par IA contre la build exacte de FatFs et l’enrobage que vous livrez ; l’outillage grand public qui a trouvé ces bugs peut trouver les suivants avant un attaquant.

Si vous exploitez des appareils affectés, traitez les ports physiques et les canaux de mise à jour firmware comme une surface d’attaque, pas comme une commodité. Limitez qui peut insérer un support dans les bornes, caméras, distributeurs et automates ; validez et signez les images firmware pour qu’une mise à jour malformée ne puisse être forcée ; et surveillez les correctifs éditeurs, en gardant à l’esprit que pour une dépendance orpheline comme celle-ci, ils peuvent mettre des années à arriver.

Statut

Référence (runZero, 1er juillet 2026)	CVSS	Effet
CVE-2026-6682	7.6 (Élevé)	Dépassement d’entier au montage FAT32 → corruption mémoire, exécution de code possible ; atteignable via certaines mises à jour firmware
CVE-2026-6687	7.6 (Élevé)	Débordement de tampon sur l’étiquette de volume exFAT (point d’appui de corruption mémoire)
CVE-2026-6688	7.6 (Élevé)	Débordement par nom de fichier long dans le code d’enrobage courant de FatFs
CVE-2026-6685	6.1 (Moyen)	Débordement de calcul dans la gestion du cache → corruption silencieuse sur volumes fragmentés
CVE-2026-6683	4.6 (Moyen)	Division par zéro exFAT ; peut « briquer » le matériel dans un flux de mise à jour
CVE-2026-6686	4.6 (Moyen)	Lecture au-delà de la fin : fuite de données de fichiers précédemment supprimés
CVE-2026-6684	4.6 (Moyen)	Table de partition GPT malformée bloquant le montage — seul correctif amont (FatFs R0.16)

Dates clés : 2017 — l’audit manuel de runZero ne trouve presque rien. Mars 2026 — l’équipe ré-audite avec VS Code + GitHub Copilot en mode « auto », le LLM construit le fuzzer. 1er juillet 2026 — divulgation coordonnée avec PoC publics ; aucune réponse de l’amont malgré l’implication du JPCERT/CC. Réserve de périmètre : l’exploitabilité varie fortement selon l’appareil, les protections mémoire et la façon dont chaque éditeur enrobe FatFs.