runZero discloses seven FatFs flaws in embedded firmware, six unpatched

FatFs is a small, permissively-licensed filesystem library that lets an embedded device read and write the FAT and exFAT formats used on USB sticks and SD cards. It is one of those pieces of code that is nearly invisible when you are looking at a product’s block diagram and nearly universal when you go pull firmware images apart. On July 1, runZero disclosed seven vulnerabilities in it, three of them at CVSS 7.6. Six of the seven are unpatched. The runZero writeup by Tod Beardsley and HD Moore lists the affected downstream stacks: Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and the SWUpdate updater. That is the physical layer of a lot of the small networked things you own without thinking of them as computers.

The seven CVEs, from runZero’s disclosure:

• CVE-2026-6682 — CVSS 7.6, High. Integer overflow while mounting a crafted FAT32 volume, leading to memory corruption and possible code execution.
• CVE-2026-6687 — CVSS 7.6, High. Buffer overflow in exFAT volume-label handling.
• CVE-2026-6688 — CVSS 7.6, High. Long-filename overflow in the wrapper code.
• CVE-2026-6685 — CVSS 6.1, Medium. Math wrap in cache handling on fragmented volumes.
• CVE-2026-6683 — CVSS 4.6, Medium. exFAT divide-by-zero crash.
• CVE-2026-6686 — CVSS 4.6, Medium. Data leak of file-extension bytes from deleted files.
• CVE-2026-6684 — CVSS 4.6, Medium. Malformed GPT partition table hangs the device. This one has an upstream fix in FatFs R0.16. The other six do not.

No in-the-wild exploitation has been reported. This is not on CISA KEV.

The trigger is a piece of media

The mechanics that matter, plainly: the affected FatFs code paths run when the device parses a filesystem it did not create — the moment somebody inserts an SD card, a USB stick, plugs in a phone in mass-storage mode, or in some designs when the device pulls firmware off removable media on boot. A crafted volume can wander into an unchecked integer arithmetic path, an unbounded copy, or a bad partition table and corrupt memory. runZero has not published weaponized proof-of-concept steps and neither will we; the runZero blog is the primary technical reference and a companion PoC repository is available for researchers.

The reachability question — “who can get a crafted volume in front of the parser?” — is where the risk actually lives, and it varies wildly by product. A security camera that mounts an SD card the operator inserted at install time has one threat model. A hardware crypto wallet asked to load a firmware update off a USB stick has another. An industrial controller sitting in a locked enclosure has a third. runZero groups the affected device population as security cameras, drones, industrial controllers, hardware crypto wallets, and other embedded systems built on FatFs-shipping RTOS distributions.

The maintainer gap

FatFs is written and maintained by a single upstream author. runZero says it “tried repeatedly to reach the maintainer” and looped in Japan’s JPCERT/CC coordination center as an escalation path. Only the GPT-hang bug (CVE-2026-6684) has received an upstream fix, and even that landed as protective GPT validation in the current release rather than a formal patch keyed to the CVE.

This is where the downstream side of the supply chain has to do work the library can’t. A one-person upstream is common in the embedded world; it isn’t inherently wrong. What is wrong is the pattern where every RTOS distribution copies the library into its tree, calls it done, and never revisits the copy again. That’s the same shape as every other quiet library-in-firmware story we’ve had — a small load-bearing piece of legacy code that stopped being maintained at the same rate the products carrying it kept shipping.

The vendors carrying FatFs know their own product surface. runZero listed them by name for a reason. Watch their PSIRT feeds — not the FatFs upstream — for the fixes.

What to actually do

There is no one-command fix. Defense is a mix of triage and reachability control, in this order:

1. Inventory whether FatFs is in your build. For most asset owners this means a call to the vendor of the product, not a grep of source you don’t have. For firmware you do build yourself on ESP-IDF, STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, TizenRT, or SWUpdate, check the vendored FatFs version in your tree. If you don’t know whether your product uses FatFs, ask.
2. For products that mount attacker-controlled media, treat the removable-media path as untrusted input. Cameras, controllers, and wallets that take user SD cards or USB sticks are the highest-exposure population. If the device runs in a physically controlled setting — locked cabinet, sealed enclosure — the practical exposure is lower and the priority is the vendor firmware update when it lands. If the device is out in the field with a slot on the front, physical-access hygiene is the interim control until the vendor patches.
3. For products that only ever mount their own media, priority is lower. A controller that reads a fixed internal flash formatted at factory time, never a user-inserted volume, is not a live path for these bugs. Still on your patch list, still not this week’s fire.
4. Watch the downstream vendors, not upstream. Espressif, STMicroelectronics, the Zephyr Project, the MicroPython team, ArduPilot, RT-Thread, Mbed, and Samsung TizenRT are where fixes will land — the FatFs upstream is not, on current evidence, going to ship them for you.

The pattern

FatFs is one of those pieces of code that lives one layer under where anybody looks. It reads the block device. It hands the filesystem primitives back up. It has been shipping quietly since the 2000s, and it works. That is what makes it valuable and also what makes it easy to forget. There are dozens of libraries in this same category across the embedded world — CoAP stacks, TLS ports, USB descriptor parsers, JPEG decoders in camera firmware — small, single-maintainer, load-bearing, invisible in the block diagram. They keep working until they don’t.

The specific work for this week is the FatFs inventory and the removable-media reachability call. The longer-standing work — the one the industry keeps not doing — is knowing which of these small load-bearing libraries are inside the firmware you ship, and having a way to move when the upstream can’t.

Start the inventory now. Ask your vendors whether they carry FatFs and, if they do, which version, and what their timeline is for the six unpatched CVEs. That is the specific email to send today.

Sourcing

• runZero disclosure: Seven vulnerabilities in FatFs
• The Hacker News: Unpatched Flaws Disclosed in Filesystem Bundled Into Millions of Embedded Devices
• Companion research repository: runZeroInc/vulns-2026-fatfs-chance
• JPCERT/CC coordination: jpcert.or.jp
• CISA Known Exploited Vulnerabilities catalog: cisa.gov/known-exploited-vulnerabilities-catalog