FatFs Vulnerabilities Put Embedded Devices and IoT Products at Risk

Security researchers at runZero have disclosed seven vulnerabilities in FatFs, a lightweight FAT and exFAT filesystem module widely used in embedded products. The flaws can be triggered through crafted FAT, exFAT, or GPT storage images and may affect devices that read USB drives, SD cards, update media, or mounted firmware packages.

The issue matters because FatFs is built for small embedded systems and appears across many downstream projects. In its FatFs vulnerability disclosure, runZero named affected ecosystems including Espressif ESP-IDF, STMicroelectronics STM32Cube middleware, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate.

The seven CVEs range from Medium to High severity. None received a Critical rating, but the risk grows in embedded environments where devices often lack address space layout randomization, memory protection, fast patching, or strong controls around removable media.

Why FatFs Bugs Have a Large Blast Radius

FatFs is popular because it is compact, portable, and easy to integrate into microcontroller projects. The official project says the module is written in ANSI C and separated from the disk control layer, which makes it independent of specific platforms and storage devices.

That portability also creates a supply-chain challenge. Many vendors copy FatFs into their firmware trees, modify it locally, and keep those versions for years. When a vulnerability appears, each vendor needs to identify its own copy, compare changes, and test patches against device-specific behavior.

runZero said the bugs can affect systems that automatically mount storage or process update media. That includes devices with exposed USB or SD card slots, as well as products that use FAT-formatted images during firmware update workflows.

Risk area	Why it matters
Removable media	Attackers may use crafted USB drives or SD cards against devices that auto-mount storage
Firmware updates	Some update pipelines process filesystem images before the main firmware runs
Embedded memory safety	Many devices lack desktop-grade exploit mitigations
Vendored code	Local forks can delay patch adoption and make exposure harder to track

The Seven FatFs Vulnerabilities

The highest-rated issue is CVE-2026-6682, a FAT32 integer overflow in mount_volume(). runZero says attacker-controlled metadata can reach downstream code that trusts file-size fields, creating a path to stack or heap memory corruption in some integrations.

Another High-severity flaw is CVE-2026-6687, an exFAT label-length bug in f_getlabel(). The issue can allow oversized writes into caller-provided buffers when exFAT support is enabled and downstream code uses small stack buffers.

The third High-severity issue, CVE-2026-6688, affects long filename handling in downstream callers. The bug pattern appears when integrations copy long FatFs filenames into fixed-size buffers without proper length checks.

CVE	Severity	Issue	Likely impact
CVE-2026-6682	High, 7.6	FAT32 integer overflow in mount_volume()	Memory corruption and possible code execution in vulnerable integrations
CVE-2026-6687	High, 7.6	exFAT label-length stack overflow in f_getlabel()	Oversized writes into caller-provided buffers
CVE-2026-6688	High, 7.6	Long filename overflow in downstream callers	Buffer overflow in wrappers that copy filenames unsafely
CVE-2026-6685	Medium, 6.1	Unsigned-subtraction wrap in dirty-cache handling	Silent corruption and out-of-bounds memory effects
CVE-2026-6683	Medium, 4.6	exFAT divide-by-zero in sync and write paths	Reliable crash or update-flow disruption
CVE-2026-6686	Medium, 4.6	Uninitialized cluster exposure after seek beyond EOF	Stale data leakage from previously deleted content
CVE-2026-6684	Medium, 4.6	GPT partition-scan loop denial of service	Very long or effectively endless mount-time scanning

Memory Corruption Risks Are the Main Concern

The most serious bugs involve memory corruption. In embedded systems, that risk can be higher than the CVSS label suggests because firmware often runs with fewer isolation layers than desktop or server software.

The CVE-2026-6682 advisory says crafted FAT32 metadata can influence file-size values that downstream applications may then use as read lengths. If an application reads attacker-controlled data into a smaller buffer, the result can become memory corruption.

The NVD entry for CVE-2026-6687 describes a stack overflow in f_getlabel() because an exFAT label length field is trusted without enforcing specification maximums. That makes it relevant for firmware that exposes volume labels to small buffers.

• Devices with public USB or SD card access may face higher physical-attack risk.
• Products that auto-mount update images should treat crafted media as untrusted input.
• Vendors should review wrapper code, not only the upstream FatFs source.
• Long filename support can create risk when application buffers still assume short names.

Some Bugs Can Break Updates or Leak Data

Not every vulnerability leads directly to code execution. Several issues still matter because they can disrupt updates, corrupt data, or expose stale information from storage.

The NVD entry for CVE-2026-6685 describes an unsigned-subtraction wrap in f_read() and f_write() during interleaved read and write activity on fragmented filesystems. runZero warned that this kind of stale dirty-cache behavior can produce silent corruption, which is difficult to detect in field devices.

CVE-2026-6683 can cause a divide-by-zero in exFAT sync or write paths, while CVE-2026-6686 can expose uninitialized cluster data after a file seek beyond end of file. These issues can affect availability, privacy, and reliability, especially in shared-media or multi-stage boot environments.

CVE-2026-6684 Is Different

CVE-2026-6684 affects FatFs versions before R0.16 when GPT scanning is enabled with FF_LBA64. The flaw allows a malformed GPT partition table to drive an extremely long or effectively infinite mount-time scan.

The CVE-2026-6684 advisory is important because runZero says upstream R0.16 already added protective GPT validation. That makes this issue different from the others, where downstream vendors still need to audit, adapt, and patch their own trees.

Vendors using older FatFs code should not assume they are safe because a newer upstream version exists. They need to check whether their local copy includes the GPT validation change and whether any local modifications reintroduced unsafe scanning behavior.

AI-Assisted Research Found Bugs Missed Earlier

runZero said the research revisited a 2017 FatFs assessment that had found only basic issues after manual review and fuzzing. In March 2026, researchers returned to the code using Visual Studio Code, GitHub Copilot in auto mode, and basic prompts.

The company said AI assistance helped build fuzzing inputs and validate exploitability across embedded scenarios. Technical details, proof-of-concept images, harnesses, and code-level analysis are available in runZero’s FatFs research repository.

This does not mean AI found the issues without human expertise. It shows that AI-assisted code review can make long-tail dependency research faster, especially in small, old, widely copied components that may not receive frequent security audits.

What Vendors Should Do Now

Device makers should first determine whether their products include FatFs, which version they use, and whether the code was modified locally. They should also check whether the filesystem stack is reachable through USB, SD card, removable media, firmware updates, boot loaders, diagnostics, or recovery modes.

The official FatFs project page lists R0.16 as the current download and notes support for features such as FAT/exFAT, long filenames, 64-bit LBA, GPT, RTOS thread safety, multiple volumes, and variable sector sizes. Those same features can change the exposure profile depending on how a vendor configures the library.

Teams should also inspect wrapper code. CVE-2026-6688, for example, depends on downstream callers that mishandle long filenames, so simply checking the core library may miss the vulnerable application pattern.

• Inventory every product, branch, bootloader, and update tool that includes FatFs.
• Compare vendored copies against upstream R0.16 and any vendor-specific patches.
• Review file-size handling, filename copying, exFAT label handling, and GPT parsing.
• Test crafted FAT, exFAT, and GPT images against update and removable-media workflows.
• Disable unnecessary exFAT, long filename, GPT, or removable-media features where possible.
• Plan signed firmware updates for affected deployed products.

Why Physical Access Can Still Be Serious

Some of the CVSS vectors describe physical access, but that should not make vendors dismiss the flaws. Many embedded devices sit in public or semi-public places where a person can briefly insert media, trigger a diagnostic flow, or interact with a maintenance port.

runZero cited examples such as security cameras with SD card storage, voting machines with USB readers, ATMs, and other devices where public touch access should not lead to compromise. The risk becomes more serious when the same filesystem parser runs in privileged boot or update contexts.

Organizations that operate embedded fleets should review exposed ports, media-mounting behavior, and update procedures while vendors prepare patches. Where possible, they should disable auto-mounting, restrict physical access, and require signed update packages.

Disclosure and Patch Status

runZero said it made repeated attempts to contact the FatFs maintainer and involved JPCERT/CC early, but did not receive a response. As a result, the disclosure focuses heavily on downstream implementers that can audit and patch their own products.

The companion repository gives researchers and vendors more technical material for validation, including harnesses and crafted images. Vendors should use those materials carefully in controlled test environments, not on production devices.

For now, the safest path is a full downstream audit. The runZero disclosure makes clear that the biggest challenge is not only the upstream library, but the large number of embedded products that copied, modified, and shipped FatFs in different ways.

FAQ