"any physical access leads to a jailbreak," runZero warned.
Seven flaws in a tiny filesystem, one large exposure
Security firm runZero has disclosed seven vulnerabilities in FatFs, a compact library that implements FAT and exFAT access for embedded devices. The set ranges from a high-severity FAT32 mount integer overflow (CVE-2026-6682, CVSS 7.6) through lower-severity crashes and information leaks. runZero ranked the bugs from Medium to High; it did not assign any Critical ratings.
The headline issue, CVE-2026-6682 (7.6, High), is an integer overflow in the FAT32 mount routine that can produce a false file size; subsequent reads using that false size can corrupt memory and, on some hardware, permit code execution. Two other Highs—CVE-2026-6687 (7.6) and CVE-2026-6688 (7.6)—allow memory corruption via an exFAT volume-label overflow and long filenames overflowing downstream wrapper code, respectively. The remaining reports cover silent corruption on fragmented volumes (CVE-2026-6685, 6.1), an exFAT divide-by-zero crash that can brick hardware during updates (CVE-2026-6683, 4.6), leftover-data leakage past file end (CVE-2026-6686, 4.6), and a GPT partition table mount hang (CVE-2026-6684, 4.6).
Where the risk lives: the devices and platforms named
FatFs is widely embedded in firmware for constrained, real-time systems. runZero named affected platforms and projects that bundle FatFs, including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and the SWUpdate updater. That places the vulnerable code in consumer IoT, industrial controllers, drones, hardware crypto wallets, and other devices built on real-time operating systems.
On many of those platforms, memory-protection features found on phones and desktops are absent. runZero’s blunt assessment: with physical access to a device’s media or some update channels, attackers can use malformed FAT/exFAT data to corrupt memory and potentially take control.
How exploitation can occur, and what runZero released
All seven flaws share a common trigger: the device attempts to read intentionally malformed storage media or a firmware image and FatFs mishandles the bad fields. Practical exploitation paths include booby-trapped USB drives, SD cards, and, for some vulnerabilities, firmware update files. runZero emphasized that the FAT32 mount bug is reachable through some firmware updates, not just physical media.
As of runZero’s July 1 disclosure, runZero reported no observed attacks exploiting these bugs, and none have surfaced since. However, runZero published proof-of-concept disk images, a test harness, and a working QEMU-based exploit example in a companion repository—meaning working exploit material is already public.
Maintenance gap: a single maintainer and limited upstream response
FatFs is maintained by one developer, and runZero said it repeatedly tried to reach that maintainer. The firm also looped in Japan’s JPCERT/CC coordination center but received no response. According to runZero, there is no upstream fix for the memory-corruption bugs, no security mailing list, and no reliable way for the many downstream products that bundle FatFs to learn they are affected.
One exception exists: CVE-2026-6684, the GPT partition-table-induced mount hang, has been fixed upstream in FatFs release R0.16. For the other six issues, runZero expects responsibility and fixes to fall to downstream vendors and integrators, a process it believes will take years rather than days—echoing the slow vendor response after the 2024 PixieFail disclosure in EDK II.
What this means for technologists, vendors, and end users
- Technologists and security teams: runZero’s advice is specific—find the copy of FatFs inside your product, audit the wrapper code that calls it, and pay special attention to how filenames and file sizes are handled. Plan to deploy patches where you can and harden update-and-media-handling code where you cannot.
- Platform vendors and integrators: because FatFs is bundled into SDKs and frameworks named by runZero (for example, Espressif ESP-IDF and STMicroelectronics STM32Cube), vendors should inventory their firmware, decide who can push updates, and prepare coordinated advisories if they ship affected images.
- End users and operators: treat physical ports and firmware-update channels as attack surfaces—limit who can plug in USB or SD media and monitor vendor firmware updates closely. The risk includes devices being crashed or bricked and, on some hardware, complete code execution after a short physical interaction.
runZero’s work also underscores a changing technical environment: the team re-audited FatFs using an off-the-shelf AI-assisted fuzzing pipeline—Visual Studio Code, GitHub Copilot in "auto" mode, and a few prompts—and found bugs missed by a 2017 manual audit. That mirrors recent findings where automated agents uncovered memory-safety defects in widely used libraries, highlighting how rapidly exploit-capable research can scale.
For now the immediate questions are concrete: will the FatFs maintainer resurface with fixes, and how quickly will the platform vendors that bundle FatFs push patches to devices in the field? Until those actions arrive, runZero’s counsel is blunt and practical—assume many shipping devices still read untrusted storage with unpatched FatFs code.
https://thehackernews.com/2026/07/unpatched-flaws-disclosed-in-filesystem.html
