Security firm runZero has uncovered seven vulnerabilities in FatFs, a lightweight filesystem library that handles FAT and exFAT formats for USB drives and SD cards. The library is embedded in a staggering number of devices: security cameras, drones, industrial controllers, hardware cryptocurrency wallets, and countless other systems running real-time operating systems.
On vulnerable devices, an attacker with physical access can plug in a malicious USB drive or SD card and execute arbitrary code. Many embedded systems lack the memory protections that desktop and mobile operating systems provide. runZero sums up the risk plainly: "any physical access leads to a jailbreak."
A public kiosk, an ATM, a camera with an SD slot, or even a voting machine should not surrender full control after a brief moment of physical contact. With FatFs, they can.
The Vulnerabilities
All seven flaws follow the same pattern: the device attempts to read a deliberately malformed storage volume or firmware image, and FatFs mishandles the corrupted data. runZero assigned CVSS scores ranging from Medium to High.
The most severe is CVE-2026-6682, an integer overflow during FAT32 volume mounting. Miscalculation results in wrong file size, that is treated as legitimate read size by subsequent code. In physical machine, it means memory corruption and full code execution.
The full list, ordered by severity:
CVE-2026-6682 (7.6, High): FAT32 mount integer overflow leading to memory corruption and possible code execution. Reachable through firmware updates as well as physical media.
CVE-2026-6687 (7.6, High): An exFAT volume-label field overflows a small buffer, providing a clean memory-corruption foothold.
CVE-2026-6688 (7.6, High): Long filenames overflow wrapper code that many projects place around FatFs, such as copying fno.fname into a fixed-size buffer. This is difficult to fix within FatFs alone.
CVE-2026-6685 (6.1, Medium): A math wrap in cache handling on fragmented volumes can silently corrupt data.
CVE-2026-6683 (4.6, Medium): An exFAT divide-by-zero crashes the device. In firmware update scenarios, it can brick hardware.
CVE-2026-6686 (4.6, Medium): A file extended beyond its end can leak leftover data from previously deleted files.
CVE-2026-6684 (4.6, Medium): A malformed GPT partition table can hang the device during mount. This is the only flaw with an upstream fix, in FatFs R0.16.
The Patching Problem
FatFs is maintained by a single developer. runZero attempted multiple times to contact the maintainer and even enlisted Japan's JPCERT/CC coordination center, but received no response.
There is no upstream fix for the memory-corruption bugs. There is no security mailing list. There is no coordinated disclosure process. Vendors that bundle FatFs have no centralized way to learn they are affected. The GPT hang is addressed in the current release, but the remaining flaws fall entirely on downstream vendors to patch themselves.
Affected platforms include Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and the SWUpdate updater. This places the burden on consumer IoT, industrial equipment, drones, and crypto wallets.
No Active Exploitation
As of runZero's July 1 disclosure, no attacks using these vulnerabilities had been reported. That status remains unchanged. However, proof-of-concept material is already public. runZero released disk images, a test harness, and a working QEMU-based exploit in a companion repository.
What to Do
For firmware developers:
1. Find your copy of FatFs in your product.
2. Audit any wrappers around the FatFs routines.
3. Be careful with filename and file size management.
4. Plan and prioritize patches.
For device operators:
1. Treat physical ports as attack surfaces
2. Restrict who can plug in media
3. Monitor for vendor firmware updates
How the Flaws Were Found
runZero first manually audited FatFs in 2017 and found little to report. In March 2026, the team applied a modern approach: Visual Studio Code, GitHub Copilot in automatic mode, and simple prompts.
The LLM generated a fuzzer that fed malformed data into FatFs until something broke. The automatic method not only discovered the bugs, but also verified their exploitability.
It is a part of a bigger picture. In late 2024, Google's Big Sleep agent found an exploitable memory bug in SQLite that traditional fuzzing missed. Just last month, an autonomous AI agent discovered 21 memory-safety issues in FFmpeg, another widely embedded C library.
runZero's conclusion is straightforward: if an off-the-shelf AI pipeline can find these vulnerabilities, so can anyone. Keeping them quiet protects no one.
The Precedent
Downstream fixes are likely to take years, not days. PixieFail offers a warning: a 2024 batch of nine vulnerabilities in EDK II network-boot code saw slow vendor responses. FatFs presents a similar challenge with a weaker fix pipeline, as there is no responsive upstream maintainer at all.
The Bottom Line
The FatFs vulnerabilities expose a vast array of embedded devices to physical access attacks. Public kiosks, ATMs, cameras, drones, and hardware wallets are all potential targets. A malicious USB drive or SD card can compromise them.
Most flaws have no upstream fix. Downstream vendors must patch their own copies. Exploit material is public.
Watch for two developments: whether the FatFs maintainer returns with patches, and how major platform vendors respond. Until then, assume that many shipping devices read untrusted storage with unfixed code.
FAQ Section
What is FatFs?
FatFs is a lightweight filesystem library that enables devices to read and write FAT and exFAT formats on USB drives and SD cards. It is widely used in embedded systems.
How many vulnerabilities were disclosed?
runZero disclosed seven vulnerabilities in FatFs. Six have no upstream fix.
Which vulnerability is the worst one?
CVE-2026-6682 – An integer overflow issue in FAT32 mount processing that can result in memory corruption and arbitrary code execution.
Which type of devices are affected?
Such devices as security cameras, drones, ICS, crypto wallets, ATM, kiosks, and other embedded devices that use FatFs.
Did the maintainer respond?
Not at all. runZero tried several times contacting him, even via JPCERT/CC, but received no response.
What should I do?
Firmware developers should audit their FatFs wrapper code. Device operators should treat physical ports as attack surfaces and watch for vendor patches.
