runZero drops seven FatFs CVEs; only CVE-2026-6684 fixed in R0.16

runZero disclosed seven CVEs in FatFs — the FAT/exFAT filesystem driver bundled into most embedded stacks — in the Seven FatFs bugs, one very large blast radius writeup published July 1. Only one of the seven, CVE-2026-6684, is fixed upstream in FatFs R0.16. The other six — including three CVSS 7.6 memory-corruption bugs — remain unpatched at the driver level, and the researchers say the maintainer never answered their disclosure attempts. A companion PoC repository with disk images, a QEMU harness and a working exploit path is public at github.com/runZeroInc/vulns-2026-fatfs-chance.

Secondary coverage: The Hacker News and cybersecuritynews.com.

The seven CVEs

Ratings and one-line summaries per the runZero blog:

• CVE-2026-6682 — CVSS 7.6, High. FAT32-mount integer overflow. Attacker-controlled arithmetic in core mount code produces a false file-size that downstream read paths trust as a length — memory corruption primitive. Reachable via firmware-update paths, not only physical media.
• CVE-2026-6683 — CVSS 4.6, Medium. Divide-by-zero in exFAT sync/write paths. Crafted media crashes the scanner; painful for OTA-update flows that mount attacker-supplied volumes.
• CVE-2026-6684 — CVSS 4.6, Medium. Missing GPT entry-count validation → unbounded partition-scan loop and mount-time DoS. The only bug fixed upstream, in R0.16.
• CVE-2026-6685 — CVSS 6.1, Medium. Unsigned-subtraction wraparound in the dirty-cache path on fragmented volumes. Leads to stale-cache behaviour and out-of-bounds effects in read/write paths.
• CVE-2026-6686 — CVSS 4.6, Medium. Seek-past-EOF exposes uninitialised cluster data — stale content from previously-deleted files leaks in shared-media and multi-stage-boot environments.
• CVE-2026-6687 — CVSS 7.6, High. exFAT volume-label field overflows a small stack buffer that most vendor examples still ship. Clean memory-corruption primitive on any firmware that enabled exFAT.
• CVE-2026-6688 — CVSS 7.6, High. With long filenames (LFN) enabled, fno.fname can exceed the fixed-size buffer that many callers wrap around f_readdir() with a strcpy(). The overflow lives in the wrapper code above FatFs, so no purely-upstream fix is possible.

Affected downstream

Per runZero, FatFs is bundled — directly or via vendor middleware — in Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT and SWUpdate, with downstream reach into consumer IoT, industrial controllers, drones, and crypto wallets. Each vendor ships a different pinned FatFs revision — usually old — and none maintains a security mailing list for FatFs consumers to subscribe to. The onus is on device teams to check.

Exploitation status

• PoCs are public. The runZero repo ships crafted disk images, a QEMU-based harness and at least one working exploitation path. No in-the-wild reports at the time of writing.
• CISA KEV: not listed. These are embedded-driver bugs; expect KEV additions only if a large product vendor issues an advisory that names a targeted campaign.
• Attack vector. Two shapes: attacker-supplied removable media (SD card, USB drive) for physical-access threat models, and attacker-supplied firmware-update artifacts for OTA paths. CVE-2026-6682 is explicitly reachable through the update-image path, not only through inserted media.

Action checklist

1. Inventory FatFs consumers. Grep vendor SDK trees for ffconf.h, ff.c and diskio.c; the version string in ff.h (FF_DEFINED, _FATFS) identifies the pinned revision. Anything before R0.16 is missing even the one fix that landed.
2. Prioritise devices that mount attacker-supplied volumes. Firmware-update recovery partitions, SD-card boot slots, USB-mass-storage-loading test rigs, drones that accept a media card. These are the CVE-2026-6682, -6687 and -6688 blast radius.
3. Disable exFAT and LFN where unused. FF_FS_EXFAT and FF_USE_LFN in ffconf.h. Turning them off closes CVE-2026-6687 (exFAT label overflow) and CVE-2026-6688 (LFN caller-buffer overflow) at the config level, without waiting for a patch that may never arrive.
4. Track vendor middleware advisories. ESP-IDF and STM32Cube historically ship FatFs updates via component-registry bumps — subscribe to Espressif Security Advisories and the STM32 middleware release notes. Zephyr's West manifest pins FatFs; watch the west.yml diff in security releases.
5. Bring PoCs in-house. The runZero disk images plus the QEMU harness cost nothing to run. If your product accepts a media card, feed them to it in QA before an attacker does.

Context

The FatFs disclosure is the second embedded-supply-chain story in a week. Our coverage of the Bad Epoll CVE-2026-46242 Linux kernel LPE landed yesterday; both cases exhibit the same pattern — a single-maintainer or narrow-team codebase whose downstream sprawl dwarfs its patch-review capacity. Bad Epoll took two months for a kernel security team to land a correct fix; FatFs has no security team at all. runZero says it tried repeatedly to reach the maintainer and looped in JPCERT/CC without success. That's why six of the seven bugs will ship with the label unpatched into whatever tomorrow's product bill-of-materials audits find.

For device makers, the operational takeaway is not "wait for R0.17." It is that pinning FatFs is now a supply-chain risk on par with pinning an unmaintained npm package: you own the patch, or you accept the CVE.