Seven newly disclosed vulnerabilities in the FatFs filesystem driver are raising fresh concerns about the security of removable-media handling across a sprawling swath of embedded platforms.
The bugs, uncovered by runZero’s research team, affect Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate, meaning the downstream blast radius touches consumer IoT devices, industrial controllers, drones, and even crypto wallets.
FatFs Bugs Expose ESP32, STM32, Zephyr Devices
FatFs, a compact FAT/exFAT driver widely embedded in firmware that touches USB drives, SD cards, and similar media, has quietly become one of those load-bearing dependencies that few users notice until something breaks.
Ranked by CVSS severity from Medium to High, none of the seven flaws hit Critical, but that’s cold comfort given how easily crafted storage media can trigger them.
The headline finding, CVE-2026-6682 (CVSS 7.6, High), lives in FatFs’s mount_volume() function. An integer overflow in core mount arithmetic can produce attacker-controlled file-size metadata that downstream code trusts as a read length a classic recipe for heap or stack overflow and potential code execution.
Given that FatFs implementations typically run without ASLR or memory protection, this isn’t a theoretical risk; it’s a direct jailbreak path for anyone with brief physical access to a device.
Two more High-severity issues follow closely behind. CVE-2026-6687 involves an uncapped exFAT label-length field in f_getlabel(), enabling oversized writes into small stack buffers common in reference implementations.
CVE-2026-6688 targets long-filename handling: when LFN support is enabled, filename buffers can exceed what calling code expects, creating overflow conditions in wrappers that use strcpy or sprintf on fixed-size fields.
The remaining four vulnerabilities carry Medium ratings but shouldn’t be dismissed:
- CVE-2026-6685: unsigned-subtraction wrap in dirty-cache handling on fragmented volumes, risking silent data corruption
- CVE-2026-6683: exFAT divide-by-zero in sync/write paths, notably implicated in some OTA update flows a potential bricking vector
- CVE-2026-6686: uninitialized cluster exposure after seeking beyond EOF, leaking stale deleted data
- CVE-2026-6684: GPT partition-scan loop causing mount-time denial of service in pre-R0.16 trees (already patched upstream)”If we can find this kind of thing with some thoughtful application of AI-assisted vuln-hunting, then so can pretty much anyone else. It’s too good a target space, and the next researcher probably won’t bother with creating validation and reproduction harnesses.” runZero research team
What makes this disclosure notable isn’t just the bug count; it’s the method. runZero first examined FatFs in 2017 through manual audit and fuzzing, finding only minor issues.
Revisiting the project in March 2026 using Visual Studio Code and GitHub Copilot in “auto” mode, with no custom harnesses or fuzzing loops, the team uncovered bugs that manual review had missed entirely.
The LLM-driven approach also helped validate exploitability across different embedded contexts, turning what was once weeks of manual labor into a far more efficient process.
FatFs exemplifies the XKCD “Dependency” problem: a tiny, unglamorous component propping up an enormous ecosystem. Because most vendors maintain locally modified, vendored copies, a single upstream patch can’t simply be dropped in each fork needs careful validation.
runZero attempted to contact the maintainer directly and looped in JPCERT/CC early in the process but received no response, leaving the burden of remediation squarely on downstream implementers.
For teams shipping firmware that touches FAT media, the guidance is direct: audit your vendored FatFs version, scrutinize wrapper code handling filenames and sizes, and treat any pending upstream patches as high priority. Technical details, proof-of-concept images, and reproduction harnesses are available in runZero’s companion research repository.
About the Author
