Unsent Errors Exposed to the File System of Millions of Embedded Devices

Security firm runZero has disclosed seven vulnerabilities in FatFs, a small system library that allows devices to read and write the FAT and exFAT formats used on USB drives and SD cards.

Errors are important because FatFs are everywhere. It is deployed within the firmware used by security cameras, drones, industrial controllers, hardware crypto wallets, and other devices built into real-time applications.

On the most affected systems, an attacker who finds a booby-trapped USB drive, SD card, or update file on a device can corrupt its memory and execute his own code.

Most embedded devices don’t have 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 shouldn’t provide full control after a moment of physical access, but here it can.

All seven bugs work in the same basic way. The device is trying to read a storage volume or a deliberately corrupted firmware image, and FatFs mishandle bad data. runZero rated the set CVSS Medium to High, excluding Criticals.

The headline bug is CVE-2026-6682 (CVSS 7.6), a complete overflow in the code that mounts a FAT32 volume. Incorrect calculations can produce a false file size, which the code later takes as the actual read length. In real hardware, that would be memory corruption and code execution.

Here are all seven, worst first according to runZero’s ranking:

• CVE-2026-6682 (7.6, Up): An overflow of FAT32 integer mounts leading to memory corruption and possible code execution. It is accessible through other firmware updates, not just physical media.
• CVE-2026-6687 (7.6, Up): the exFAT volume’s label field overflows the small buffer, giving an attacker a clean surface for memory corruption.
• CVE-2026-6688 (7.6, Up): long filenames overflow code for wrapping multiple projects placed around FatFs, such as strcpy for fno.fname into a fixed buffer. It is difficult to adjust within FatFs only.
• CVE-2026-6685 (6.1, Medium): statistical folding in cache management on partitioned volumes can silently corrupt data.
• CVE-2026-6683 (4.6, Medium): exFAT partition zero crashes the device. In the update flow, it can brick the hardware. It is also available with other firmware updates.
• CVE-2026-6686 (4.6, Medium): a file that has been extended past its end can leak data left over from previously deleted files.
• CVE-2026-6684 (4.6, Medium): an incorrect GPT partition table (disk map) can hang the device during mounting. It is the only one of seven fixed upstream, at FatFs R0.16.

Here is the hard part. FatFs is maintained by a single developer in a small corner of the internet, and runZero says it has tried several times to reach the maintainer and was put through the JPCERT/CC coordination center in Japan, with no response.

With a runZero account, there are no upstream fixes for memory-corrupting bugs, no security mailing lists, and no way for many products including FatFs to learn that they are affected. The update helps with the GPT hang, as the current release prevents it, but the rest falls to downstream vendors to patch themselves.

runZero names affected platforms, including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate updater. That narrows the problem down to consumer IoT, industrial gear, drones, and crypto wallets.

Since the disclosure of runZero on July 1, no attacks have been reported using these bugs, and none have appeared since then. But the exploit material is already public: runZero has posted proof-of-concept disk images, a test harness, and a QEMU-based exploit example to a friend site.

If you are building a firmware that affects FAT or exFAT media, the advice is straightforward. Get a copy of FatFs on your product, research the wrapper code around it, take a hard look at how it handles filenames and file sizes, and plan for patching.

If you use affected devices, treat virtual ports and update channels as an attack surface: limit who can connect media, and watch for vendor firmware updates.

Why does this keep happening

runZero first manually checked FatFs in 2017 and found little to report. Back in March 2026, the team identified an off-the-shelf setup with the same code: Visual Studio Code, GitHub Copilot in “auto” mode, and a few obvious commands.

LLM built a fuzzer, a tool that feeds incorrect data into code until something breaks. For those bugs that came to light manual research testing was missed and helped ensure they were usable.

That fits a growing pattern. In late 2024, Google’s Big Sleep agent discovered a real, exploitable memory flaw in SQLite that was missed by standard fuzzing.

Just last month, an independent AI agent revealed 21 memory protection bugs in FFmpeg, another widely embedded C library. runZero’s point is unclear: if an off-the-shelf AI pipeline can find these, so can anyone, so sitting quietly on them isn’t protecting anyone.

The patch problem is common. runZero expects upstream fixes to take years, not days, and PixieFail is an example: a 2024 batch of nine bugs in the network-boot code of EDK II, the firmware behind many PC and server products, that vendors were slow to integrate. FatFs have a similar shape and a weak correction pipeline, because there is no upstream reaction at all.

Watch two things: whether the FatFs guardian will appear again in the episode, and how the vendors of the main platform that integrates it react. Until they do, imagine a bunch of shipping devices reading untrusted storage with uneditable code behind it.