Sette nuove vulnerabilità in FatFs, la libreria FAT/exFAT più diffusa nel mondo embedded, mettono a rischio milioni di dispositivi IoT, controllori industriali, drone, telecamere di sicurezza e persino hardware wallet. A scoprirle è stato il team di ricerca runZero, che ha rispolverato un audit di sicurezza del 2017 usando un approccio decisamente più moderno: Visual Studio Code e GitHub Copilot in modalità “auto”, con prompt semplici e nessun tooling custom. Il risultato è stato sorprendente: bug che il fuzzing manuale non aveva mai individuato sono emersi con relativa facilità.
Per chi lavora su sistemi embedded, firmware o dispositivi IoT, questa vicenda merita attenzione non solo per i dettagli tecnici delle CVE, ma anche per quello che rivela sulla fragilità della supply chain del software embedded.
Cos’è FatFs e perché è ovunque
FatFs è una libreria open source compatta, scritta in C, che permette a dispositivi con risorse limitate di leggere e scrivere volumi formattati FAT e exFAT — gli stessi filesystem usati da chiavette USB e schede SD. Proprio per la sua leggerezza è stata integrata, spesso tramite vendoring (copia diretta del codice sorgente nel proprio progetto), in un numero enorme di piattaforme embedded:
- Espressif ESP-IDF
- STMicroelectronics STM32Cube
- Zephyr RTOS
- MicroPython
- ArduPilot
- RT-Thread
- Mbed
- Samsung TizenRT
- SWUpdate
A valle di questi framework troviamo dispositivi IoT di consumo, controllori industriali, drone, hardware crypto wallet, telecamere con slot SD, chioschi pubblici, ATM e persino macchine per il voto elettronico con lettori USB. La maggior parte di questi dispositivi non dispone delle protezioni di memoria che diamo per scontate su desktop e smartphone, a partire dall’ASLR (Address Space Layout Randomization).
Le sette vulnerabilità
Tutte le CVE condividono lo stesso schema di innesco: il dispositivo legge un volume di storage o un’immagine firmware malformata, FatFs gestisce male i dati corrotti, e da lì partono corruzioni di memoria, crash o fughe di informazioni. Due delle sette CVE, la 6682 e la 6683, sono implicate anche nei processi di aggiornamento firmware over-the-air, il che estende la superficie di attacco ben oltre il semplice accesso fisico al dispositivo.
Le tre vulnerabilità più severe (CVSS 7.6, High)
CVE-2026-6682 - Integer overflow in mount_volume() (FAT32)
Un overflow intero può produrre metadati di dimensione file
controllati dall'attaccante. Se questo valore viene usato come
lunghezza di lettura da codice a valle, si arriva a corruzione
di heap/stack e potenziale esecuzione di codice arbitrario.
CVE-2026-6687 - Stack overflow in f_getlabel() (exFAT)
La gestione della label exFAT non limita correttamente la
lunghezza del campo, permettendo scritture oversize nel buffer
della label. Corruzione di memoria diretta nel firmware.
CVE-2026-6688 - Overflow nei filename lunghi
Quando fno.fname supera le dimensioni del buffer fisso nel
codice chiamante, il problema si manifesta tipicamente in
wrapper che usano strcpy o sprintf senza controlli di bound.
Le quattro vulnerabilità di severità media (CVSS 4.6–6.1)
CVE-2026-6685 (CVSS 6.1) - Wraparound in sottrazione unsigned
nella gestione della dirty-cache su volumi frammentati: può
corrompere memoria o causare corruzione silente dei dati,
particolarmente pericolosa in sistemi di logging e controllo.
CVE-2026-6683 (CVSS 4.6) - Divide-by-zero in exFAT nei percorsi
di sync/write, innescabile con media malformati: crash affidabili
e possibile "brick" del dispositivo durante update firmware.
CVE-2026-6686 (CVSS 4.6) - Esposizione di cluster non
inizializzati quando si estende un file oltre EOF: può rivelare
dati residui di file precedentemente cancellati (data leak).
CVE-2026-6684 (CVSS 4.6) - Loop di scansione GPT nelle versioni
precedenti a R0.16: può causare scansioni illimitate e denial
of service al boot. Corretta in R0.16, ma resta presente in
gran parte dei deployment embedded esistenti.
Il vero problema: chi la corregge?
FatFs è mantenuta da un solo sviluppatore. runZero ha tentato ripetutamente di contattarlo e ha coinvolto JPCERT/CC nel processo di coordinamento, senza ottenere risposta. Il risultato è che, delle sette CVE, solo quella relativa alla scansione GPT (CVE-2026-6684) ha una patch upstream disponibile, nella versione R0.16.
Ma anche questa correzione non risolve automaticamente nulla: praticamente tutti i produttori che integrano FatFs lavorano su copie vendorizzate e modificate localmente. Ogni patch upstream deve quindi essere validata con cura prima di essere incorporata nel proprio codice, un processo che — come insegna il precedente di PixieFail (le nove vulnerabilità in EDK II divulgate nel 2024) — può richiedere anni, non settimane.
Cosa fare se sviluppi o gestisci dispositivi con FatFs
Se sei tra chi costruisce firmware che interagisce con storage FAT o exFAT, le priorità immediate sono chiare:
- Individua la copia vendorizzata di FatFs nel tuo codice e verificane la versione
- Fai il audit del wrapper code che circonda le chiamate a FatFs, in particolare come vengono gestiti nomi file e dimensioni
- Presta particolare attenzione a qualsiasi punto in cui
fno.fnameviene copiato in un buffer di dimensione fissa - Pianifica la validazione e il rilascio di patch per la tua base di codice specifica
Se invece gestisci dispositivi che integrano FatFs senza averli sviluppati (telecamere, NAS embedded, sistemi industriali), tratta le porte fisiche e i canali di aggiornamento firmware come superficie di attacco: limita chi può inserire fisicamente supporti removibili, monitora gli advisory di sicurezza dei vendor e applica gli aggiornamenti firmware non appena disponibili.
runZero ha pubblicato immagini disco proof-of-concept, un test harness e una dimostrazione di exploit basata su QEMU in un repository di accompagnamento. Alla data di divulgazione (1 luglio 2026) non risultavano attacchi noti che sfruttassero attivamente queste vulnerabilità — ma la disponibilità pubblica di PoC e tooling di fuzzing basato su AI riduce drasticamente il tempo necessario perché qualcuno le sfrutti.
Conclusione
Il caso FatFs è un promemoria di quanto sia fragile la catena di fornitura del software embedded: componenti piccoli, utili e copiati ovunque, che diventano difficili da correggere proprio per la loro diffusione capillare e la mancanza di un processo di manutenzione strutturato. È anche un caso di studio interessante sull’uso di strumenti AI-assisted (Copilot in modalità agente) per il security auditing: un processo che nel 2017 richiedeva settimane di fuzzing manuale, nel 2026 è stato in parte automatizzato con risultati migliori. Per i team che gestiscono flotte di dispositivi embedded, il messaggio pratico è di trattare ogni libreria di terze parti vendorizzata come debito tecnico da monitorare attivamente, non come un componente “impostato e dimenticato”.
Fonte: Security Affairs e 4sysops, basato sulla ricerca originale di runZero.