Security firm runZero has disclosed seven vulnerabilities in FatFs, a small filesystem library that lets a device read and write the FAT and exFAT formats used on USB drives and SD cards.
The flaws matter because FatFs is nearly everywhere. It ships inside the firmware that runs security cameras, drones, industrial controllers, hardware crypto wallets, and other devices built on real-time operating systems.
On the worst-affected systems, an attacker who gets a booby-trapped USB drive, SD card, or update file onto a device can corrupt its memory and run their own code.
Many embedded devices lack the memory protections found on phones and desktops, which is why runZero says “any physical access leads to a jailbreak.” A public kiosk, a camera with an SD slot, an ATM, or a voting machine with a USB port should not hand over full control after a moment of physical access, but here it can.
All seven bugs work the same basic way. The device tries to read a storage volume or firmware image that has been deliberately malformed, and FatFs mishandles the bad data. runZero rated the set CVSS Medium to High, with no Criticals.
The headline bug is CVE-2026-6682 (CVSS 7.6), an integer overflow in the code that mounts a FAT32 volume. Bad math can produce a false file size, which later code treats as a real read length. On real hardware, that can become memory corruption and code execution.
Here are all seven, worst first by runZero’s ranking:
- CVE-2026-6682 (7.6, High): FAT32 mount integer overflow leading to memory corruption and possible code execution. Reachable through some firmware updates, not just physical media.
- CVE-2026-6687 (7.6, High): an exFAT volume-label field overflows a small buffer, giving an attacker a clean memory-corruption foothold.
- CVE-2026-6688 (7.6, High): long filenames overflow the wrapper code many projects put around FatFs, such as a strcpy of fno.fname into a fixed buffer. Hard to fix inside FatFs alone.
- CVE-2026-6685 (6.1, Medium): a math wrap in cache handling on fragmented volumes that can silently corrupt data.
- CVE-2026-6683 (4.6, Medium): an exFAT divide-by-zero that crashes the device. In an update flow, it can brick hardware. Also reachable through some firmware updates.
- CVE-2026-6686 (4.6, Medium): a file extended past its end can leak leftover data from previously deleted files.
- CVE-2026-6684 (4.6, Medium): a malformed GPT partition table (the disk’s map) can hang the device during mount. It is the only one of the seven fixed upstream, in FatFs R0.16.
Here is the hard part. FatFs is maintained by one developer in a small corner of the internet, and runZero says it tried repeatedly to reach the maintainer and looped in Japan’s JPCERT/CC coordination center, with no response.
By runZero’s account, there is no upstream fix for the memory-corruption bugs, no security mailing list, and no way for the many products that bundle FatFs to learn they are affected. Updating helps with the GPT hang, since the current release blocks it, but the rest fall 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. That pushes the problem downstream into consumer IoT, industrial gear, drones, and crypto wallets.
As of runZero’s July 1 disclosure, no attacks using these bugs had been reported, and none have surfaced since. But the exploit material is already public: runZero shipped proof-of-concept disk images, a test harness, and a working QEMU-based exploit example in a companion repository.
If you build firmware that touches FAT or exFAT media, the advice is direct. Find the copy of FatFs in your product, audit the wrapper code around it, look hard at how you handle filenames and file sizes, and plan to patch.
If you run affected devices, treat physical ports and update channels as an attack surface: limit who can plug in media, and watch for vendor firmware updates.
Why this keeps happening
runZero first audited FatFs by hand in 2017 and found little worth reporting. Returning in March 2026, the team pointed an off-the-shelf setup at the same code: Visual Studio Code, GitHub Copilot in “auto” mode, and a few plain prompts.
The LLM built a fuzzer, a tool that feeds malformed data into code until something breaks. That surfaced bugs the manual audit had missed and helped confirm they were exploitable.
That fits a growing pattern. In late 2024, Google’s Big Sleep agent found a real, exploitable memory bug in SQLite that ordinary fuzzing had missed.
Just last month, an autonomous AI agent surfaced 21 memory-safety bugs in FFmpeg, another widely embedded C library. runZero’s point is blunt: if a mostly off-the-shelf AI pipeline can find these, so can anyone, so sitting on them quietly protects no one.
The patching problem is familiar. runZero expects downstream fixes to take years, not days, and PixieFail is the precedent: a 2024 batch of nine bugs in the network-boot code of EDK II, the firmware behind many PC and server brands, that vendors were slow to patch. FatFs has the same shape and a weaker fix pipeline, because there is no responsive upstream at all.
Watch for two things: whether the FatFs maintainer resurfaces with a patch, and how the big platform vendors that bundle it respond. Until they do, assume that plenty of shipping devices read untrusted storage with code that has no fix behind it.
