Heads up! If you ship firmware that touches FAT media (think any removable storage, like USB drives and SDCards), you'll want to pay attention to this post. This work was part of runZero's research into long-tail supply chain bug hunting using LLMs. We live in the future!
Today, we're publishing seven CVEs documenting several vulnerabilities in FatFs project, ranging from CVSS Medium to High (no Criticals, phew!). The affected ecosystem includes some major non-hobby platforms like Espressif ESP-IDF, STMicroelectronics STM32Cube middleware, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate, with downstream reach into consumer IoT, industrial controllers, drones, crypto wallets, and more.
This project is a return to a security assessment started back in 2017, when a manual audit and multi-day fuzzing effort identified some basic, but not compelling, bugs in the FatFs driver. Nine years later, in March of 2026, we revisited this project using Visual Studio Code, GitHub Copilot in "auto" mode, and some basic prompts, all without any specific loops, harnesses, or skills. The results were surprising. Bugs that were overlooked during the manual audit became trivial to find by using the LLM to automatically build a fuzzer with novel inputs. Not only did this effort find interesting and reportable bugs, it also automated the process of validating that these bugs are actually exploitable across different embedded scenarios.
So, why do FatFs bugs matter? 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. 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.
However, the attacker value is straightforward: these issues are triggerable by crafted FAT/exFAT/GPT images, often through removable media or update channels that get mounted automatically. Note that CVE-2026-6682 and 6683 are both implicated in some OTA update processes for firmware.
This post is intentionally light on exploit internals. For technical details, PoC images, harnesses, and code-level analysis, see runZero's companion research repository:
The findings, ordered by criticality #
The seven findings documented here are listed roughly in order of subjective attacker value.
FAT32 integer overflow in mount_volume() #
(CVSS 7.6, High) – This is the headline issue: CVE-206-6682 describes integer overflow in core mount arithmetic can produce attacker-controlled file-size metadata that downstream code may trust as a read length. In real systems, that can become a heap/stack overflow and code execution. In terms of practical attacker value plus transitive impact, this is at the top of the stack.
exFAT label-length stack overflow in f_getlabel() #
(CVSS 7.6, High) – CVE-2026-6687 describes a condition where the exFAT label length field is not adequately capped, enabling oversized writes into caller-provided label buffers. This is especially painful where canonical examples and generated code use small stack buffers. It is a clean memory-corruption primitive in a path many firmware projects expose, at least where exFAT has been enabled.
Long filename overflow in downstream callers #
(CVSS 7.6, High) – With LFN enabled, fno.fname can be much larger than many caller buffers expect, as described by CVE-2026-6688. The bug class appears repeatedly in integrations (strcpy, sprintf, fixed-size name/path fields). This one is tricky to fix entirely in FatFs directly (since exploitation depends on wrappers copying long filenames into undersized local buffers), but it could be mitigated by FatFs changes that make filename lengths and truncation/validation outcomes more explicit to callers.
Unsigned-subtraction wrap in dirty-cache handling #
(CVSS 6.1, Medium) – CVE-2026-6685 describes a condition where on fragmented volumes, arithmetic wrap can drive stale dirty-cache behavior and out-of-bounds memory effects in read/write paths. This can manifest as silent corruption, which is exactly the kind of bug operators hate most: hard to detect, easy to misdiagnose, and dangerous in control/data-logging workloads.
exFAT divide-by-zero in sync/write paths #
(CVSS 4.6, Medium) – CVE-2026-6683 documents a divide-by-zero condition in exFAT sync/write flows that can be triggered by crafted media and produce reliable crash behavior. In update contexts, this can become a practical bricking vector. While generally more "DoS than RCE," it still offers meaningful attacker value against availability, especially given the OTA implications.
Uninitialized cluster exposure after seek beyond EOF #
(CVSS 4.6, Medium) – CVE-2026-6686 describes an uninitialized-cluster exposure path where extending files beyond EOF can leak stale data from previously deleted content. It is an information-disclosure bug with real consequences in multi-stage boot/update and shared-media environments.
GPT partition-scan loop DoS (pre-R0.16) #
(CVSS 4.6, Medium) – CVE-2026-6684 covers a GPT entry-count abuse case that can trigger effectively unbounded scanning in older trees. That creates a severe mount-time DoS in affected pre-R0.16 implementations, especially painful in boot paths, but it is ranked last here because upstream R0.16 added protective GPT validation. Now, it's up to implementers to upgrade.
XKCD "Dependency" strikes again #
If you have seen XKCD 2347 ("Dependency"), you already know where this is going: one component, maintained in one tiny corner of the internet, quietly supports an absurd amount of modern cyber-stuff.
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. 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.
We made repeated attempts to contact the maintainer, and we involved JPCERT/CC early on as well. We did not receive a response. So, this publication is aimed at the people who can still do something useful right now: downstream implementors. Audit your vendored version, audit your wrappers, audit your file-name and file-size handling, and plan for patch updates.
Also, keeping this class of issue quiet in 2026 would be almost entirely security theater, now that we've entered the age of the apex agentic adversary. If we can find this kind of thing with some thoughtful application of AI-assisted vuln-hunting, then so can pretty much anyone else. Sure, this took a little HD Moore-branded stubbornness, but even so, we don’t believe these are going to stay undiscovered for very long. It’s too good a target space, and the next researcher probably won’t bother with creating validation and reproduction harnesses.
When it comes to vulnerability disclosure, I've always believed that I'm merely the most recent person to learn about the issue, and that's more true now than ever in this hyper-automated code auditing world. Better to disclose, coordinate where possible, and in the end, publish in order to give defenders the head's up.
PS. Looking for exploits? You can find a test harness, a full qemu-based exploit example, and corrupt FatFs images in the repository.
