TL;DR
- what: runZero disclosed seven vulnerabilities in FatFs, a tiny FAT/exFAT filesystem library embedded in the firmware of millions of RTOS-based devices.
- impact: On devices without memory protection, a malformed USB drive, SD card, or firmware image can corrupt memory and run attacker code, meaning any physical access can lead to full compromise.
- fix: Only CVE-2026-6684 (GPT hang) is patched upstream in FatFs R0.16; the memory-corruption bugs have no upstream fix and fall to downstream vendors to patch individually.
- who: Anyone shipping or running firmware built on ESP-IDF, STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, or SWUpdate that reads FAT/exFAT media.
Security firm runZero has disclosed seven vulnerabilities in FatFs, a small library that lets embedded devices read and write the FAT and exFAT formats used on USB drives and SD cards. The library is nearly ubiquitous: it ships inside firmware running security cameras, drones, industrial controllers, hardware crypto wallets, and countless other real-time operating system (RTOS) devices. 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 execute their own code.
The blast radius is the story here. Many embedded devices lack the memory protections found on phones and desktops, which is why runZero flatly concludes that "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. With FatFs in the firmware, it can.
How all seven bugs work
The mechanism is identical across the set. 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 batch CVSS Medium to High, with no Criticals. The headline bug is CVE-2026-6682 (CVSS 7.6), an integer overflow in the FAT32 mount routine: bad math produces a false file size that later code treats as a real read length, which on real hardware becomes memory corruption and code execution. Critically, it is reachable through some firmware update flows, not just physical media.
- CVE-2026-6682 (7.6, High) — FAT32 mount integer overflow leading to memory corruption and possible code execution. Reachable via some firmware updates.
- CVE-2026-6687 (7.6, High) — an exFAT volume-label field overflows a small buffer, giving a clean memory-corruption foothold.
- CVE-2026-6688 (7.6, High) — long filenames overflow the wrapper code many projects put around FatFs (e.g. a strcpy of fno.fname into a fixed buffer). Hard to fix in 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 and can brick hardware in an update flow. Also reachable via 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 can hang the device during mount. The only one fixed upstream, in FatFs R0.16.
The real problem: no upstream to patch
FatFs is maintained by a single developer in a quiet corner of the internet. runZero says it tried repeatedly to reach the maintainer and looped in Japan's JPCERT/CC coordination center, and got no response. The result: no upstream fix for the memory-corruption bugs, no security mailing list, and no channel for the many products bundling FatFs to even learn they are affected. Updating to R0.16 stops the GPT hang, but the other six fall to downstream vendors to patch on their own.
⚠️ Exploit material is already public — As of the July 1 disclosure no in-the-wild attacks had been reported. But runZero shipped proof-of-concept disk images, a test harness, and a working QEMU-based exploit example in a companion repository. The barrier to weaponization is low, and the clock started the day it went public.
Who's exposed
runZero named affected platforms including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Arm Mbed, Samsung TizenRT, and the SWUpdate updater. That pushes the exposure deep into consumer IoT, industrial gear, drones, and crypto wallets. Because so many of these SDKs are the default starting point for new hardware, the vulnerable code is duplicated across an enormous and largely uncounted fleet of shipping products.
What to do now
If you build firmware that touches FAT or exFAT media: locate your copy of FatFs, audit the wrapper code around it, scrutinize how you handle filenames and file sizes (CVE-2026-6688 lives in that wrapper, not in FatFs itself), and plan to patch. If you operate affected devices, treat physical ports and update channels as live attack surface: restrict who can plug in media, lock down SD and USB slots on kiosks and field equipment, and watch for vendor firmware updates.
For IT and OT managers — Inventory devices with exposed USB/SD ports in public or semi-trusted areas first (kiosks, cameras, ATMs, controllers). Physical access is the primary vector, so port control and tamper monitoring buy time while you wait on vendor patches that may take months to years.
Why this keeps happening
runZero hand-audited FatFs back in 2017 and found little worth reporting. Returning in March 2026, the team pointed an off-the-shelf setup at the same code: VS Code, GitHub Copilot in "auto" mode, and a few plain prompts. The LLM built a fuzzer that surfaced bugs the manual audit had missed and helped confirm they were exploitable. It fits a growing pattern: Google's Big Sleep agent found a real, exploitable SQLite bug in late 2024, and an autonomous AI agent surfaced 21 memory-safety bugs in FFmpeg just last month. 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 points to PixieFail as precedent: a 2024 batch of nine bugs in the EDK II network-boot code 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 two things: whether the maintainer resurfaces with a patch, and how the big platform vendors bundling FatFs respond. Until they do, assume plenty of shipping devices read untrusted storage with code that has no fix behind it.
Originally published on RedEye Threat Intelligence.
Top comments (0)