Seven Unpatched Flaws in a Tiny Filesystem Library Put Millions of Embedded Devices at Risk
A security research firm has just handed the embedded systems world an uncomfortable problem. runZero has disclosed seven vulnerabilities in FatFs, a compact filesystem library used to read and write FAT and exFAT formatted storage — the same formats your USB drives and SD cards use. The catch: six of the seven have no upstream fix, and the maintainer has gone quiet.
FatFs is everywhere it shouldn't be taken for granted. It ships inside firmware for security cameras, drones, industrial controllers, hardware crypto wallets, and a sprawling range of devices built on real-time operating systems. If your product handles removable storage and runs on a microcontroller, there is a reasonable chance FatFs is in there.
The bugs all follow the same basic pattern. Feed the library a deliberately malformed storage volume or firmware image, and it mishandles the bad data. On constrained embedded hardware with no memory protection, that mishandling can escalate quickly. runZero puts it plainly: on the worst-affected systems, physical access becomes a jailbreak. A kiosk with a USB slot, a camera with an SD card reader, an ATM — none of these should hand over full code execution to anyone with a malformed drive, but with vulnerable FatFs versions, they might.
runZero rated the bugs CVSS Medium to High. No Criticals, but the High-rated ones are the sort that keep firmware engineers up at night.
The worst is CVE-2026-6682 (CVSS 7.6), an integer overflow in the FAT32 volume mounting code. The bad arithmetic produces a false file size, which downstream code then treats as a legitimate read length. On real hardware, that path leads to memory corruption and potential code execution. It is also reachable through some firmware update flows, not just physical media, which somewhat undermines the 'just lock the USB port' mitigation.
Two more High-rated bugs round out the top tier. CVE-2026-6687 involves an exFAT volume-label field that overflows a small buffer, offering an attacker a clean memory corruption foothold. CVE-2026-6688 targets long filename handling in the wrapper code many projects put around FatFs, where a strcpy of a filename into a fixed buffer can overflow. That last one is awkward to fix inside FatFs itself, because the problem often lives in how projects integrate the library.
The Medium-rated bugs are a mixed bag. CVE-2026-6685 is a maths wrap in cache handling on fragmented volumes that can silently corrupt data. CVE-2026-6683 is an exFAT divide-by-zero that crashes the device and can brick hardware if it hits during an update flow. CVE-2026-6686 allows a file extended past its own end to leak data from previously deleted files. CVE-2026-6684 causes a hang during mount when presented with a malformed GPT partition table — and is the only one of the seven that has actually been fixed upstream, in FatFs release R0.16.
One fix out of seven is not a great ratio.
The coordination story is grim. FatFs is maintained by a single developer. runZero says it made repeated attempts to make contact and brought in Japan's JPCERT/CC to help facilitate disclosure. Nothing came back. There is no security mailing list, no CVE process, and no mechanism for the many products bundling FatFs to find out they are affected. Updating to R0.16 addresses the GPT hang. The memory corruption bugs are downstream vendors' problem now.
The affected platforms named by runZero include Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and the SWUpdate updater. That list covers consumer IoT, industrial equipment, drones, and cryptocurrency hardware. It is not a small blast radius.
As of runZero's July 1 disclosure, no attacks exploiting these bugs had been reported. That may not last long. runZero published proof-of-concept disk images, a test harness, and a working QEMU-based exploit alongside the disclosure. The exploit material is already public, which is a deliberate choice — more on that below.
If you build firmware that touches FAT or exFAT media, the immediate task is finding your copy of FatFs, auditing whatever wrapper code sits around it, and reviewing how your code handles filenames and file sizes. If you operate devices with exposed physical ports, treat those ports as an attack surface and watch vendor update channels closely.
How these bugs were found matters as much as what they are. runZero audited FatFs manually back in 2017 and found little worth reporting. Returning in March 2026, the team ran the same code through a fairly modest AI-assisted setup: Visual Studio Code, GitHub Copilot in auto mode, and a handful of prompts. The LLM assembled a fuzzer, the fuzzer found bugs the manual audit had missed, and the team confirmed exploitability.
This is part of a pattern that is becoming hard to ignore. In late 2024, Google's Big Sleep agent found a real exploitable memory bug in SQLite that conventional fuzzing had overlooked. Last month, an autonomous AI agent surfaced 21 memory-safety bugs in FFmpeg. runZero's point is not subtle: if an off-the-shelf AI pipeline can find these vulnerabilities, so can anyone motivated to look, which makes sitting on them quietly a bad strategy.
The patching timeline for embedded systems is notoriously slow. runZero points to PixieFail, a 2024 set of nine bugs in EDK II network boot code, as a precedent for how long these things drag on even when there is a responsive upstream. FatFs has no responsive upstream at all. Expect fixes from platform vendors to take a long time, and assume that plenty of devices currently shipping will be reading untrusted storage with vulnerable code for years to come.