An off-the-shelf AI fuzzer found seven flaws in FatFs, embedded in millions of devices

What is this?

On July 1, 2026, security firm runZero disclosed seven vulnerabilities in FatFs, a tiny C library that lets embedded devices read and write the FAT and exFAT formats used by USB sticks and SD cards. FatFs is not obscure: it ships inside the firmware of security cameras, drones, industrial controllers, hardware crypto wallets, and countless other real-time systems. On the worst-affected devices, a booby-trapped storage volume or firmware image can corrupt memory and run attacker code — and because many embedded chips lack the memory protections found on phones and PCs, runZero frames the impact bluntly: “any physical access leads to a jailbreak.”

The technical bugs are ordinary memory-safety mistakes. What makes the disclosure worth reading is how they were found. runZero had already audited FatFs by hand back in 2017 and found little worth reporting. Returning in March 2026, the team pointed an almost entirely off-the-shelf setup at the same code — Visual Studio Code, GitHub Copilot in “auto” mode, and a few plain prompts — and let the model build a fuzzer. That harness surfaced bugs the human audit had missed, and helped confirm they were reachable.

How it works

A fuzzer is a tool that feeds malformed input into a program until something breaks. Writing a good one for a filesystem parser normally takes real effort: you have to understand the on-disk structures, generate mutated disk images, and wire up a harness that can mount them and catch crashes. In this case the LLM did that scaffolding from natural-language prompts, and the resulting fuzzer explored the parsing code more thoroughly than a one-off manual review.

Every one of the seven findings follows the same shape. The device tries to read a storage volume or update image that has been deliberately corrupted, and FatFs mishandles the bad data. The headline issue is an integer overflow in the code that mounts a FAT32 volume: bad arithmetic yields a false file size, which later code trusts as a real read length — on real hardware that can become memory corruption and code execution. Others include an exFAT volume-label field that overflows a small buffer, long filenames that overflow the wrapper code many projects wrap around FatFs, a cache-handling math wrap that silently corrupts data on fragmented volumes, an exFAT divide-by-zero that can brick hardware during an update, and a read-past-end that leaks leftover bytes from previously deleted files. runZero rated the set CVSS Medium to High, with no Criticals, and shipped proof-of-concept disk images and a QEMU-based test harness in a public companion repository so vendors can reproduce and verify fixes.

runZero is explicit that this is not a one-off trick. The same pattern has been building for over a year: Google’s Big Sleep agent found a real, exploitable memory bug in SQLite in late 2024 that traditional fuzzing had missed, and in June 2026 an autonomous agent surfaced 21 memory-safety bugs in FFmpeg, another widely embedded C library. The team’s point is that if a mostly off-the-shelf AI pipeline can find these, so can anyone.

Why it matters

Two things changed here, and only one of them is the code. The first is the economics of discovery. Auditing a decades-old C parser used to require a specialist’s time and patience; now a developer with a commodity coding assistant can stand up an effective fuzzing harness in an afternoon. That lowers the bar for defenders — and equally for attackers, who no longer need deep filesystem expertise to go looking for the next FatFs.

The second is the disclosure pipeline, which has not scaled with the discovery. FatFs is maintained by a single developer, and runZero says it tried repeatedly to reach the maintainer and looped in Japan’s JPCERT/CC coordination center without a response. As a result there is no upstream fix for the memory-corruption bugs, no security mailing list, and no channel to tell the many products that bundle FatFs that they are exposed. Only one of the seven — a denial-of-service hang from a malformed partition table — is fixed upstream, in release R0.16. Everything else falls to downstream vendors to patch on their own. runZero names affected platforms including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and the SWUpdate updater — which pushes the problem into consumer IoT, industrial gear, drones, and crypto wallets. The precedent runZero cites is PixieFail, a 2024 batch of firmware bugs that vendors were slow to fix; FatFs has the same shape and a weaker fix pipeline, because there is no responsive upstream at all. As of the disclosure, no in-the-wild attacks had been reported.

Defenses

The uncomfortable lesson is that “no one has bothered to look” is no longer a defense, because looking is now cheap. Both builders and operators have concrete moves.

If you ship firmware that touches FAT or exFAT media, find the copy of FatFs in your product and treat it as an untrusted parser handling attacker-controlled input. Audit the wrapper code around it — the strcpy-into-a-fixed-buffer patterns are where several of these bugs actually land — and look hard at how you compute filenames and file sizes. Pull in the upstream R0.16 release for the partition-table fix, and backport or mitigate the memory-corruption issues yourself, since no upstream patch exists. Where the hardware supports it, enable memory protection (MPU/MMU regions, stack canaries, W^X) so a parsing bug is a crash rather than a jailbreak. Consider running your own AI-assisted fuzzing pass against the exact FatFs build and wrapper you ship; the same commodity tooling that found these bugs can find the next ones before an attacker does.

If you operate affected devices, treat physical ports and firmware update channels as an attack surface, not a convenience. Limit who can plug media into kiosks, cameras, ATMs, and controllers; validate and sign firmware images so a malformed update cannot be forced through; and watch for vendor patches, understanding that for orphaned dependencies like this one they may take years to arrive.

Status

Reference (runZero, July 1, 2026)	CVSS	Effect
CVE-2026-6682	7.6 (High)	FAT32 mount integer overflow → memory corruption, possible code execution; reachable via some firmware updates
CVE-2026-6687	7.6 (High)	exFAT volume-label buffer overflow (memory-corruption foothold)
CVE-2026-6688	7.6 (High)	Long-filename overflow in common FatFs wrapper code
CVE-2026-6685	6.1 (Medium)	Cache-handling math wrap → silent data corruption on fragmented volumes
CVE-2026-6683	4.6 (Medium)	exFAT divide-by-zero crash; can brick hardware in an update flow
CVE-2026-6686	4.6 (Medium)	Read-past-end leaks data from previously deleted files
CVE-2026-6684	4.6 (Medium)	Malformed GPT partition table hangs mount — only one fixed upstream (FatFs R0.16)

Key dates: 2017 — runZero’s manual audit finds little. March 2026 — team re-audits with VS Code + GitHub Copilot “auto” mode, LLM builds the fuzzer. July 1, 2026 — coordinated disclosure with public PoCs; no upstream maintainer response despite JPCERT/CC involvement. Scope caveat: exploitability varies widely by device, memory protections, and how each vendor wraps FatFs.