# Seven Unpatched Flaws in Ubiquitous FatFs Library Put Millions of Embedded Devices at Physical-Access Risk


## The Threat


Security researchers at runZero have disclosed seven critical vulnerabilities in FatFs, a lightweight filesystem library that handles FAT and exFAT formats across millions of embedded devices worldwide. The library is fundamental infrastructure for devices that need to read or write data from USB drives, SD cards, and firmware update files—making these bugs a systemic problem rather than an isolated issue.


The severity lies in FatFs's ubiquity. It's embedded in security cameras, drones, industrial controllers, hardware cryptocurrency wallets, HVAC systems, medical devices, and other embedded systems built on real-time operating systems (RTOS). Many of these devices lack the memory protections—Address Space Layout Randomization (ASLR), Data Execution Prevention (DEP), stack canaries—that protect smartphones and desktop computers. As runZero's researchers note, on vulnerable hardware, "any physical access leads to a jailbreak."


An attacker who introduces a malformed USB drive, SD card, or firmware update onto a vulnerable device can trigger memory corruption that escalates to arbitrary code execution. In devices like public-facing kiosks, ATMs, voting machines, security cameras with SD card slots, or airport scanners, a few seconds of physical access shouldn't grant full system compromise—yet these vulnerabilities make that possible.


## Severity and Impact


| CVE | CVSS Score | Severity | Vector | CWE | Attack Surface |

|-----|-----------|----------|--------|-----|-----------------|

| CVE-2026-6682 | 7.6 | High | Integer Overflow (FAT32 Mount) | CWE-190 | Firmware updates, USB/SD media |

| CVE-2026-6687 | 7.6 | High | Buffer Overflow (exFAT Label) | CWE-120 | exFAT volumes |

| CVE-2026-6688 | 7.6 | High | Filename Buffer Overflow | CWE-120 | Long filename handling |

| CVE-2026-6685 | 6.1 | Medium | Cache Math Wrap / Data Corruption | CWE-190 | Fragmented volumes |

| CVE-2026-6683 | 4.6 | Medium | Divide-by-Zero (exFAT) | CWE-369 | exFAT parsing, firmware updates |

| CVE-2026-6686 | 4.6 | Medium | Information Disclosure | CWE-416 | File deletion edge cases |

| CVE-2026-6684 | 4.6 | Medium | Malformed GPT Hang | CWE-835 | Partition table parsing |


Critical Detail: Only CVE-2026-6684 (the lowest-impact flaw) has been fixed upstream in FatFs R0.16. The six memory-corruption and code-execution bugs remain unpatched at the source.


## Affected Products


FatFs is distributed through multiple major embedded platforms and RTOS ecosystems:


Microcontroller & RTOS Platforms:

  • Espressif ESP-IDF (ESP32, ESP8266, and successors)
  • STMicroelectronics STM32Cube
  • Zephyr RTOS
  • MicroPython
  • RT-Thread RTOS
  • Mbed OS
  • Samsung TizenRT

    • Software & Tools:

  • SWUpdate (over-the-air firmware update framework)
  • ArduPilot (drone autopilot firmware)

    • Device Categories at Risk:

  • Security cameras and video surveillance systems
  • Unmanned aerial vehicles (UAVs/drones)
  • Industrial controllers and PLCs
  • Hardware security keys and cryptocurrency wallets
  • IoT sensors and gateways
  • Medical devices
  • Automotive infotainment and telematics systems

    • ## Mitigations


    For Device Manufacturers and Firmware Developers:


    1. Immediate audit: Identify whether your firmware includes FatFs. Check your codebase, RTOS distribution, and third-party SDK components for ff.h or fatfs references.


    2. Input validation: Harden wrapper code around FatFs. Validate filename lengths, file sizes, and partition table structure before passing data to the library. Use bounds-checking functions (strncpy instead of strcpy) in any code that interfaces with FatFs.


    3. Disable exFAT if not needed: If your device only requires FAT32, configure FatFs to disable exFAT support and reduce attack surface.


    4. Firmware update authentication: Validate the cryptographic signature of firmware images before mounting them for processing. Do not mount arbitrary storage without verification.


    5. Memory protection: Where hardware supports it (ARM with MPU, x86 with PAE), enable memory protection units to prevent exploits from executing injected code, even if memory corruption occurs.


    6. Patch planning: Contact your RTOS vendor (Espressif, STM, Zephyr, etc.) for security updates. Request a timeline and patch availability. Many vendors will backport fixes to multiple LTS branches.


    7. Physical access controls: For devices in public spaces (ATMs, voting machines, kiosks), restrict or disable USB/SD card slots where possible, or implement tamper detection.


    For End Users and Operators:


  • Do not insert unknown USB drives or SD cards into embedded devices in critical environments.
  • Update device firmware to the latest available version from the manufacturer.
  • Monitor for security advisories from your device vendor.

    • ## References


  • runZero Advisory: https://www.runzero.com/blog/fatfs-vulnerabilities/
  • FatFs Official Repository: http://elm-chan.org/fsw/ff/
  • JPCERT/CC Disclosure: https://www.jpcert.or.jp/ (coordinated disclosure tracking)
  • Affected Platform Updates:

    • - Espressif: https://www.espressif.com/

    - STMicroelectronics: https://www.st.com/

    - Zephyr Project: https://www.zephyrproject.org/

    - SWUpdate: https://swupdate.org/


    ---


    ## HackWire Analysis


    The FatFs vulnerability disclosure reveals a structural fragility in embedded systems security: a single unmaintained library has become foundational infrastructure for millions of devices. The runZero team's inability to reach the FatFs maintainer and the lack of a formal security disclosure process underscores a critical gap in the open-source embedded ecosystem.


    Unlike Linux kernel security issues, which route through dedicated channels (kernel.org, LKML, CVE programs), FatFs exists in a regulatory vacuum. One developer in an unknown timezone, with no published contact channel, maintains code that runs inside cameras, drones, medical devices, and financial systems. When that maintainer is unreachable, the entire supply chain stalls.


    The practical impact is asymmetric. Researchers publicly released proof-of-concept exploits, disk images, and working QEMU examples. Fixing these bugs now depends on each downstream vendor independently identifying that FatFs is in their product, understanding the patches, and shipping updates—a process that typically takes months if it happens at all. For legacy devices (medical equipment, industrial controllers) with no update mechanism, the vulnerabilities are permanent.


    What's particularly concerning is the physical-access requirement being treated as acceptable risk on systems that shouldn't be accessible. A voting machine shouldn't boot untrusted code because someone plugged in a USB stick. A connected medical device shouldn't execute arbitrary firmware from an SD card. Yet the FatFs bugs make these attacks possible. Defenders need to ask hard questions: Does this device need USB/SD support at all? Can we disable it? Can we validate input more aggressively before it reaches the filesystem layer?


    For vendors shipping new products, this is a wake-up call to audit your dependency tree—especially in embedded stacks where bill-of-materials scrutiny is rare. The responsible move is to update to FatFs R0.16 immediately (which fixes the divide-by-zero) and begin detailed review of wrapper code to catch the remaining six flaws. Even better: consider whether your product can function without FAT or exFAT support, eliminating the risk entirely.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)