FatFs CVE-2026-6682: Seven Bugs Hit Embedded Devices

FatFs maintainers and downstream firmware vendors have a new embedded-security problem to triage: runZero disclosed seven vulnerabilities in the widely copied FAT/exFAT filesystem library, including three High-severity bugs that can turn crafted USB media, SD cards, or update images into memory-corruption triggers on affected devices.^[1]

The headline issue is CVE-2026-6682, a FAT32 integer-overflow flaw in mount_volume(). The CVE record says FatFs R0.16 and earlier can calculate attacker-controlled file-size metadata that downstream code may trust as a read length, creating an unsafe path toward heap or stack corruption in real integrations.^[2] runZero rated it CVSS 7.6 High and says some firmware update flows can reach it, which makes this more than a “someone plugged in a bad USB stick” scenario.^[1]

FatFs is small, portable C code, and that is exactly why the blast radius is awkward. The library is vendored into embedded SDKs, RTOS projects, bootloaders, updater components, drones, cameras, industrial controllers, hardware wallets, and other products that need to read FAT or exFAT media. runZero’s public repository lists affected or potentially affected ecosystems including Espressif ESP-IDF, STMicroelectronics STM32Cube middleware, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed OS, RIOT, NodeMCU firmware, and SWUpdate.^[3]

That profile should sound familiar to administrators who already track firmware-heavy risk, from UniFi OS exploit chains to Lantronix EDS5000 root RCE and router botnets such as C0XMO targeting DD-WRT devices. The exposed component may be different, but the operational problem is the same: firmware dependencies are often copied, modified, and patched slowly.

What firmware teams should check first

The seven CVEs are not all equal. CVE-2026-6682, CVE-2026-6687, and CVE-2026-6688 carry the highest practical risk because they involve memory-corruption paths. CVE-2026-6687 affects exFAT label handling in f_getlabel(), while CVE-2026-6688 describes a common downstream-caller pattern where long FatFs filenames are copied into undersized fixed buffers.^[4]

The remaining issues still matter for products that mount untrusted media or depend on storage during boot and update workflows. CVE-2026-6683 can crash exFAT write/sync logic through divide-by-zero behavior, CVE-2026-6685 can create stale dirty-cache behavior and data corruption on fragmented filesystems, CVE-2026-6686 can expose stale data after file extension beyond EOF, and CVE-2026-6684 can cause mount-time denial of service in pre-R0.16 GPT scanning paths.^[4]

There is one important constraint for readers: runZero says it had not seen in-the-wild attacks at disclosure time. This is still worth covering because exploit material is already public. The companion GitHub repository includes a test harness, fuzzer material, corrupt disk images, and a QEMU-based exploit example, so defenders should assume the proof path is available to both researchers and opportunistic attackers.^[3]

Device owners usually cannot patch FatFs directly. Their useful action is to identify products that accept removable media or firmware images, restrict public or untrusted access to those ports, avoid unverified update files, and watch vendor advisories for firmware rebuilt with patched downstream code. Public kiosks, cameras with SD slots, field-service USB workflows, and industrial devices that auto-mount media deserve extra attention.

Firmware builders and product security teams have more work. Search for vendored ff.c copies, map which FatFs version and configuration flags are compiled into each product, check whether exFAT, LFN, GPT, or update-path mounting is enabled, and audit wrapper code for filename and file-size assumptions. The safest triage question is simple: can an attacker influence any FAT/exFAT/GPT image that this product parses before authentication or before a trusted boot/update boundary?

runZero also noted a disclosure problem: repeated attempts to reach the upstream maintainer, including coordination through JPCERT/CC, did not produce a response before publication.^[1] That means downstream vendors should not wait for a single upstream security release to solve everything. FatFs R0.16 helps with the GPT loop issue, but the memory-corruption cases need project-by-project review, wrapper hardening, and vendor firmware updates.

References

1. runZero Research. “Seven FatFs bugs, one very large blast radius.” Updated July 1, 2026. https://www.runzero.com/blog/fatfs-bugs/
2. CVE Program. “CVE-2026-6682.” Published July 1, 2026. https://cveawg.mitre.org/api/cve/CVE-2026-6682
3. runZeroInc. “vulns-2026-fatfs-chance.” GitHub research repository. https://github.com/runZeroInc/vulns-2026-fatfs-chance
4. The Hacker News. “Unpatched Flaws Disclosed in Filesystem Bundled Into Millions of Embedded Devices.” July 3, 2026. https://thehackernews.com/2026/07/unpatched-flaws-disclosed-in-filesystem.html