Seven Bugs in FatFs Put IoT and Embedded Devices at Risk

Pierluigi Paganini
July 06, 2026

runZero found 7 flaws in FatFs, a filesystem used in IoT and embedded devices. Bugs can cause memory corruption, crashes, or data leaks via crafted storage.

Cybersecurity firm runZero has disclosed seven vulnerabilities in FatFs, a compact open-source library that lets embedded devices read and write FAT and exFAT formatted storage, the same formats used on USB drives and SD cards. The severity ratings run from CVSS Medium to High.

This project revisited a 2017 security audit of the FatFs driver, where manual testing and fuzzing had only found minor issues. In March 2026, the team repeated the analysis using Visual Studio Code and GitHub Copilot in auto mode with simple prompts and no custom tooling. The results were unexpected: issues previously missed became easy to find. The AI helped generate fuzzing inputs automatically and even validated exploitability across different embedded environments, turning what was once a manual, time-consuming process into something far more automated and effective.

The flaws impact multiple platforms, including Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate. Downstream from those platforms sit consumer IoT devices, industrial controllers, drones, hardware crypto wallets, and more.

Most of the devices that bundle FatFs don’t have the memory protections that phones and desktops take for granted, such as ASLR.

“For the vendors who build on these platforms it’s simple: any physical access leads to a jailbreak, especially given the lack of address space layout randomization (ASLR) and memory protection. For everyone else, there are numerous devices where brief physical access by the general public should not lead to a full compromise.” states the report. “For example, security cameras with SDCard storage, voting machines with USB file readers, ATMs, and pretty much anything else that has a screen that you expect people to touch.”

A security camera with an SD card slot, a voting machine with a USB reader, an ATM, a public kiosk: none of these should hand over full control to whoever plugs in a drive, but on unpatched hardware running vulnerable FatFs code, that’s the exposure.

All seven bugs share the same trigger: a device reads a crafted storage volume or firmware image, FatFs mishandles the malformed data, and bad things follow. Two of the CVEs, CVE-2026-6682 and CVE-2026-6683, are also implicated in over-the-air firmware update processes, which extends the attack surface beyond physical media entirely.

Below are the details of the seven flaws:

• CVE-2026-6682 (CVSS 7.6, High) – FAT32 integer overflow in mount_volume() can produce attacker-controlled file-size metadata. This may be trusted as a read length by downstream code, leading to heap or stack corruption and possible code execution.
• CVE-2026-6687 (CVSS 7.6, High) – exFAT label-length stack overflow in f_getlabel() allows oversized writes into label buffers when the label field is not properly capped. This can lead to straightforward memory corruption in embedded firmware.
• CVE-2026-6688 (CVSS 7.6, High) – long filename overflow in downstream callers where fno.fname exceeds fixed-size buffers. This often breaks in wrapper code using strcpy or sprintf and depends heavily on how firmware handles filenames.
• CVE-2026-6685 (CVSS 6.1, Medium) – unsigned subtraction wrap in dirty-cache handling on fragmented volumes can corrupt memory or cause silent data corruption, which is especially dangerous in logging and control systems.
• CVE-2026-6683 (CVSS 4.6, Medium) – exFAT divide-by-zero in sync/write paths triggered by crafted media leads to reliable crashes and potential device bricking in firmware update scenarios.
• CVE-2026-6686 (CVSS 4.6, Medium) – uninitialized cluster exposure when extending files past EOF can leak stale data from previously deleted files, creating an information disclosure risk.
• CVE-2026-6684 (CVSS 4.6, Medium) – GPT partition scan loop in pre-R0.16 versions can trigger unbounded scanning, causing boot-time denial of service. It is fixed upstream, but still present in older embedded deployments.

FatFs is maintained by one developer. runZero made repeated attempts to reach the maintainer and involved JPCERT/CC in the coordination process. Neither effort produced a response. For six of the seven CVEs, there is no upstream patch. The only fix available is the GPT scan issue addressed in R0.16, and even that requires downstream vendors to update their vendored copies.

That last detail is the crux of the problem.

“FatFs is one of those components. It’s compact, useful, and copied everywhere. That’s great for shipping products quickly, but less great when memory-safety issues show up in parser-adjacent code that happily ingests untrusted media.” continues the report. “This kind of component is even more challenging to deal with, from a disclosure-and-fix perspective, in that nearly everyone ends up making local, vendored modifications. So, an upstream patch must be validated pretty carefully before incorporating.”

Even when a fix does eventually appear, every vendor that’s diverged from upstream has to validate it against their own modifications before shipping it. The precedent from PixieFail, nine vulnerabilities in EDK II network boot code disclosed in 2024, is that this process takes years, not weeks, and FatFs has a weaker fix pipeline because there’s no responsive upstream at all.

runZero published proof-of-concept disk images, a test harness, and a working QEMU-based exploit demonstration in a companion repository at github.com/runZeroInc/vulns-2026-fatfs-chance. No attacks using these bugs had been reported as of the July 1 disclosure date.

What to do if you ship or run affected products?

If you build firmware that touches FAT or exFAT storage, the immediate work is: find your vendored copy of FatFs, audit the wrapper code around it, examine how your code handles filenames and file sizes, and plan for patching. Pay particular attention to any code that copies fno.fname into a fixed-size buffer. If you run affected devices rather than build them, treat physical ports and firmware update channels as attack surface: restrict who can plug in media, monitor for vendor security advisories, and apply firmware updates when vendors release them.

The broader point runZero makes is worth sitting with. Keeping these bugs quiet in 2026 would accomplish nothing, because the tooling that found them is now widely available. The right response to that reality is disclosure, coordination where possible, and publication to give defenders a head start.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon