Sei falle su sette senza patch in un software per droni, telecamere e wallet hardware: le ha trovate un'IA

Sette vulnerabilità, sei delle quali senza alcuna patch disponibile. È quanto ha scoperto runZero in FatFs, la libreria C scritta da ChaN (elm-chan.org) che gestisce filesystem FAT, exFAT e GPT e che, distribuita royalty-free, è finita compilata dentro il firmware di una quantità enorme di dispositivi embedded: telecamere di sicurezza, droni, controller industriali, wallet hardware per criptovalute.

Le piattaforme confermate come affette includono Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed OS, Samsung TizenRT e SWUpdate. Nel repository di ricerca pubblicato da runZero compare una tabella di 20 progetti open source con la versione di FatFs vendorizzata e i CVE applicabili: fra i più esposti MicroPython, ancora fermo alla release R0.13c del 2019.

Il bug più grave: overflow deterministico senza protezioni

Il problema più serio è CVE-2026-6682 (CVSS 7.6, High), un integer overflow in mount_volume(). Il campo BPB_FATSz32, moltiplicato per il numero di FAT (fasize *= fs->n_fats), può wrappare e produrre metadati di dimensione file controllati dall'attaccante; il codice a valle può poi usare quel valore come lunghezza di lettura, generando un overflow su heap o stack ed esecuzione di codice arbitrario. Su sistemi bare-metal privi di ASLR e protezione della memoria, condizione comune nell'embedded, lo sfruttamento è deterministico e non richiede heap spray, brute force né una fuga di informazioni preliminare.

Le altre sei falle coprono un ventaglio ampio di effetti. CVE-2026-6687 (CVSS 7.6) nasce da un campo exFAT (XDIR_NumLabel) letto come byte grezzo senza il limite previsto dalla specifica: con un valore di 128, la chiamata a f_getlabel() può mandare in overflow il buffer del chiamante fino a 244 byte. Il dettaglio rilevante è che il pattern di buffer vulnerabile, char label[12], è generato automaticamente da STM32CubeMX in ogni progetto FatFs che produce: secondo runZero la popolazione di firmware STM32 commerciali interessati è "enorme e in larga parte non catalogata". CVE-2026-6688 (CVSS 7.6) riguarda invece le integrazioni che copiano in buffer fissi, senza controllo, i nomi lunghi fino a 255 caratteri restituiti da f_readdir() quando i long file name sono abilitati.

Fra i bug di gravità media, CVE-2026-6685 (CVSS 6.1) è una sottrazione senza segno che su volumi frammentati può corrompere silenziosamente la memoria. CVE-2026-6683 (CVSS 4.6) è un divide-by-zero in sync_fs() che causa un crash affidabile a ogni scrittura o sincronizzazione: in un flusso di aggiornamento OTA può arrivare a rendere inutilizzabile il dispositivo. Sia questo bug sia CVE-2026-6682 sono raggiungibili anche attraverso alcuni processi di aggiornamento firmware via rete, non solo tramite supporto fisico. CVE-2026-6686 (CVSS 4.6) permette invece di leggere dati di file già cancellati, comprese chiavi o porzioni di firmware, allocando nuovi cluster senza azzerarli. L'unico dei sette con un fix upstream è CVE-2026-6684 (CVSS 4.6), un loop illimitato nella scansione GPT corretto dalla versione R0.16 di FatFs con un nuovo controllo che limita il numero di partizioni lette.

Gli scenari di attacco individuati da runZero sono due: l'inserimento fisico di un supporto rimovibile malevolo, come una SD card o una chiavetta USB, che innesca il mount automatico; oppure una pipeline OTA che consegna in rete un'immagine firmware malevola a dispositivi che non ne verificano l'integrità prima di montarla con FatFs. Al momento della divulgazione, il 1° luglio 2026, non risultavano attacchi noti che sfruttano queste falle.

Un maintainer solo, nessun canale di sicurezza

FatFs è mantenuta da un singolo sviluppatore. runZero ha tentato ripetutamente di contattarlo e ha coinvolto JPCERT/CC come coordinatore, senza ottenere risposta. Non esiste una mailing list di sicurezza dedicata né un meccanismo di notifica delle patch: ogni progetto downstream che ha vendorizzato il file ff.c deve scoprire, valutare e correggere le falle per conto proprio. runZero stima che i fix a valle richiederanno anni.

Il precedente citato dalla stessa runZero è PixieFail, il gruppo di nove vulnerabilità nel codice di rete-boot di EDK II di cui abbiamo già parlato nel 2024, per cui i vendor furono lenti a rilasciare patch. FatFs condivide la stessa forma del problema, con una pipeline di correzione ancora più debole perché manca del tutto un upstream reattivo.

Interessante anche il modo in cui runZero è arrivata a questi risultati. Un'analisi manuale del codice, condotta già nel 2017, non aveva trovato nulla di rilevante. A marzo 2026 il team ha ripreso il lavoro usando Visual Studio Code e GitHub Copilot in modalità autonoma, con prompt testuali senza harness specifici: l'LLM ha costruito da solo un fuzzer che ha individuato i bug sfuggiti alla revisione manuale e ha automatizzato la verifica dell'exploitability. runZero accosta il caso ad altri episodi recenti di vulnerability hunting assistito da IA, come il bug in SQLite trovato da Google Big Sleep e i 21 bug di memory safety individuati da un agente autonomo in FFmpeg il mese precedente.

Sul repository GitHub pubblicato da runZero sono disponibili, per ciascuna delle sette falle, disk image di proof-of-concept, un test harness deterministico, un fuzzer Go con corpus seed e un esempio di exploit RCE su QEMU per CVE-2026-6682: materiale già pronto per chi debba validare l'esposizione dei propri dispositivi.