Skip to content

FatFs CVE-2026-6682 to CVE-2026-6688 embedded-filesystem bug cluster

Summary

runZero Research disclosed seven vulnerabilities in FatFs, a small FAT/exFAT filesystem implementation that is copied into many embedded and firmware stacks. The issues span memory corruption, denial of service, and information disclosure. The highest-value cases are reachable through crafted FAT/exFAT/GPT images that a device mounts from removable media or, in some firmware designs, through update channels.

The affected ecosystem is broad because FatFs is used directly or transitively by embedded platforms and projects such as Espressif ESP-IDF, STMicroelectronics STM32Cube middleware, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate. runZero specifically calls out downstream reach into consumer IoT, industrial controllers, drones, crypto wallets, and other products where filesystem parsing can sit in boot, logging, removable-media, or firmware-update paths.

Tags

Why this matters

  • FatFs is a long-tail supply-chain dependency: product teams often inherit it through board-support packages, RTOS middleware, SDK examples, or copied firmware code rather than tracking it like a normal package-manager dependency.
  • Physical access to removable media should not imply full device compromise, yet runZero notes that crafted FAT/exFAT/GPT images can become jailbreak primitives on devices without ASLR or memory protection.
  • Some paths are not limited to hands-on attacks. runZero says CVE-2026-6682 and CVE-2026-6683 are implicated in some OTA update processes, making firmware-update parsers part of the risk surface.
  • Public proof-of-concept images, harnesses, and code-level analysis are available in runZero's companion repository. That helps defenders reproduce exposure, but also lowers the barrier for exploit development against products that have not mapped their FatFs usage.
  • The blast radius is product-specific: impact depends on whether FAT32, exFAT, GPT, long-file-name support, removable storage, OTA packages, or wrapper code paths are enabled in a given firmware build.

Vulnerability cluster

CVE runZero description Defender interpretation
CVE-2026-6682 FAT32 integer overflow in mount_volume(); crafted metadata can produce a false file size later trusted as a read length. Highest-priority memory-corruption case; assess removable-media and update-image mount paths.
CVE-2026-6687 exFAT label-length stack overflow in f_getlabel(). Treat exFAT-enabled firmware and small stack buffers in sample/generated code as high risk.
CVE-2026-6688 Long-file-name overflow in downstream callers that copy fno.fname into undersized buffers. Audit wrapper/application code around FatFs, not only the upstream library.
CVE-2026-6685 Unsigned-subtraction wrap in dirty-cache handling on fragmented volumes. Look for silent corruption and out-of-bounds memory effects in read/write paths.
CVE-2026-6683 exFAT divide-by-zero in sync/write paths. Availability/bricking risk, especially if firmware-update flows mount attacker-influenced images.
CVE-2026-6686 Uninitialized-cluster exposure after seek beyond EOF. Data-leak risk in shared-media, boot/update, logging, or multi-stage processing contexts.
CVE-2026-6684 GPT partition-scan loop denial of service in pre-R0.16 implementations. Mount-time DoS; upstream R0.16 added protective GPT validation, but copied/downstream trees need verification.

Affected surface to inventory

  1. Products, appliances, lab gear, cameras, wallets, drones, industrial controllers, and boot/update components that mount FAT, FAT32, exFAT, or GPT-formatted media.
  2. Firmware-update workflows that accept archives, disk images, USB/SD payloads, or OTA packages that are mounted or parsed by FatFs before signature enforcement or with incomplete validation.
  3. Vendor SDKs and RTOS stacks carrying FatFs: Espressif ESP-IDF, STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, SWUpdate, and board-vendor forks.
  4. Application wrappers that copy FatFs filenames, labels, paths, or file-size metadata into fixed-size buffers.
  5. Safety, voting, medical, access-control, and kiosk-like environments where untrusted users can briefly touch removable media slots or update interfaces.

Defender guidance

  1. Build a product inventory of FatFs usage. Search firmware source, SBOMs, SDK imports, and copied files for ff.c, ff.h, f_mount, f_getlabel, f_readdir, fno.fname, exFAT support, GPT parsing, and long-file-name configuration.
  2. Pull upstream/vendor fixes where available, but do not assume that an RTOS or board-support-package update reached copied firmware trees. Diff the actual shipped code.
  3. Disable unneeded exFAT, GPT, long-file-name, removable-media, and update-image mount paths in hardened builds.
  4. Enforce firmware-update signature and integrity checks before filesystem mounting where architecture allows it. If mounting is unavoidable, mount in the smallest possible privilege/domain and fail closed on malformed images.
  5. Audit wrapper code for fixed buffers and unsafe copies from FatFs structures. CVE-2026-6688 is explicitly a downstream-integration class, so an upstream library patch may not remove product-specific bugs.
  6. For exposed devices, add operational controls: block or epoxy unused USB/SD slots, monitor update attempts, document accepted media formats, and require trusted-maintenance procedures.
  7. Treat crashes or boot loops after media insertion or update processing as potential exploitation attempts. Preserve the media image, update package, firmware build, serial logs, watchdog resets, and device memory dumps if available.

Sources

  • runZero Research: https://www.runzero.com/blog/fatfs-bugs/
  • runZero companion research repository: https://github.com/runZeroInc/vulns-2026-fatfs-chance
  • FatFs project: https://elm-chan.org/fsw/ff/
  • The Hacker News: https://thehackernews.com/2026/07/unpatched-flaws-disclosed-in-filesystem.html