Security firm runZero has disclosed seven vulnerabilities in FatFs, a small file system library that lets devices read and write the FAT and exFAT formats used on USB drives and SD cards.
The flaws matter because FatFs are almost everywhere. It is shipped 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 corrupted USB drive, SD card, or update file on the device can corrupt its memory and run his code.
Many embedded devices lack the memory protection found on phones and desktops, which is why RunZero says, “Any physical access leads to jailbreak.” A public kiosk, a camera with an SD slot, an ATM, or a voting machine with a USB port should not hand over complete control after a moment of physical access, but here it can.
All seven bugs work in the same basic way. The device tries to read a storage volume or firmware image that has been intentionally corrupted, and FatFs mishandles the corrupted data. RunZero rated the set’s CVSS as medium to high, with no criticals.
The headline bug is CVE-2026-6682 (CVSS 7.6), which is an integer overflow in the code that mounts a FAT32 volume. Bad math can produce an incorrect file size, which the code then treats as the actual read length. On real hardware, this can lead to memory corruption and code execution.
Here are all seven, ranked by RunZero as the worst:
- CVE-2026-6682 (7.6, High): FAT32 mount integer overflow causes memory corruption and possible code execution. Accessible not only on physical media, but also through certain firmware updates.
- CVE-2026-6687 (7.6, High): An exFAT volume-label field overflows a small buffer, giving the 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 strcpy of fno.fname into a fixed buffer. Difficult to fix inside FatFs alone.
- CVE-2026-6685 (6.1, Medium): A math wrap in cache management on fragmented volumes that can silently corrupt data.
- CVE-2026-6683 (4.6, Medium): An exFAT divide-by-zero that crashes the device. In the update flow, it may damage the hardware. Also accessible via some firmware updates.
- CVE-2026-6686 (4.6, Medium): A file extended beyond its end may leak residual data from previously deleted files.
- CVE-2026-6684 (4.6, Medium): A corrupted GPT partition table (map of the disk) can cause the device to hang during mount. This is the only one of the seven fixed upstream in FatFs R0.16.
Here’s the hard part. FatFs is maintained by a 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, but got no response.
By RunZero’s account, there is no upstream fix for the memory-corruption bug, no security mailing list, and no way for the many products that bundle FATF to let them know they are affected. Updating helps with GPT hangs, as the current release blocks it, but the rest is up to downstream vendors to fix themselves.
RunZero named the affected platforms including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, MBID, Samsung TizenRT, and SWUpdate Updater. This pushes the problem into consumer IoT, industrial gear, drones, and crypto wallets.
As of RunZero’s July 1 disclosure, no attacks using these bugs were reported, and none have been reported since. But the exploit material is already public: RunZero has shipped proof-of-concept disk images, a test harness, and a working QEMU-based exploit example to a partner repository.
If you create firmware that touches FAT or exFAT media, the advice is straightforward. Find a copy of FatFs in your product, audit the wrapper code around it, look carefully at how you handle file names 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 keep an eye on vendor firmware updates.
Why does this keep happening
RunZero first hand-audited FATF in 2017 and found no reporting material. Returning in March 2026, the team pointed to an off-the-shelf setup based on the same code: Visual Studio Code, GitHub Copilot in “auto” mode, and a few plain hints.
LLM created a fuzzer, a tool that feeds distorted data into code until something breaks. This revealed bugs that were missed in manual audits and helped confirm that they were exploitable.
This fits the growing pattern. In late 2024, Google’s Big Sleep agent found a real, exploitable memory bug in SQLite that was missed by normal fuzzing.
Just last month, an autonomous AI agent exposed 21 memory-protection bugs in FFmpeg, another widely embedded C library. RunZero’s point is clear: if most off-the-shelf AI pipelines can find them, so can anyone, so sitting idly by on them protects no one.
The patching problem is familiar. RunZero expects downstream fixes to take years, not days, and PixieFail is an example: a 2024 batch of nine bugs in the network-boot code of the EDK II, the firmware behind many PC and server brands, which vendors were slow to patch. FatFs is similar in size and has a weak fix pipeline, as it has no reactive upstream.
Keep an eye on two things: whether FatFs comes out again with a maintainer patch, and how the big platform vendors that bundle it respond. Until they do, assume that a lot of shipping devices read untrusted storage with code that has no fix behind it.
