The recent disclosure of seven FatFs vulnerabilities by researchers at cyber asset attack surface management provider runZero underscores the cyber-physical device patching challenges that will escalate in the years ahead. It’s a set of complex challenges defenders should prepare for.
Tod Beardsley, VP of security research at runZero, and HD Moore, the company's founder and CEO, disclosed the seven CVEs on July 1. The set of CVEs affect FatFs, a compact C library that handles FAT, exFAT, and GPT media parsing in embedded systems. The affected platforms include Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate.
The resulting end-user exposure from the disclosure is profound and extends across consumer IoT devices, industrial controllers, drones, ATMs, security cameras, voting machines, and even cryptocurrency wallets. CVE scores range from 4.6 to 7.6 on the CVSS scale.
Why were these flaws uncovered now? “It's unlikely FatFs ever went through a proper, public security audit,” Beardsley explained to CYBR.SEC.Media. “FatFs doesn't appear to be implicated in any CVE-identified vulnerabilities before today. That’s a big red flag,” he said.
Beardsley added that their assessment picks up where a previous surface scan by Beardsley and Moore left off in 2017, before the advent of cheap and easy AI-assisted bug hunting. “The previous findings weren't interesting enough to report on. By using an LLM, this exercise found exploitable security vulnerabilities and made the job of putting together testing and reproduction material much easier,” Beardsley said.
The Firmware Patch Chain Rarely Completes
As more cyber-physical devices come online, the challenges associated with patching physical devices will remain steep. Devices with embedded firmware are distributed across physical locations, often without the capability to update remotely. And because FATFS is compact and portable, it is frequently used in devices and modified by each downstream implementer. That means no single upstream patch resolves the problem across the ecosystem. Each platform maintainer must independently validate and integrate a fix, and then device manufacturers must push it to deployed hardware.
In many real-world environments, that chain never completes.
For this batch of vulnerabilities, Beardsley and Moore said they made repeated attempts to contact the FatFs maintainer and involved JPCERT/CC in the coordination effort. They received no response. Device implementors, the teams closest to deployed devices, appear to be the only parties positioned to act.
The technical findings vary in severity, but several are directly exploitable.
The headline vulnerability, CVE-2026-6682 (CVSS 7.6), is an integer overflow in core FAT32 mount arithmetic that can produce attacker-controlled file-size metadata downstream code may use as a read length — a path to heap or stack overflow and potential code execution. CVE-2026-6687 (CVSS 7.6) involves a stack overflow triggered by inadequately capped exFAT label-length fields. CVE-2026-6688 (CVSS 7.6) documents long-filename overflows in downstream callers, a bug class that recurs across integrations where caller buffers assume shorter filenames.
The remaining four include a CVSS 6.1 unsigned-subtraction wrap that can manifest as silent data corruption in fragmented volumes. That kind of failure that is hard to detect and easy to misdiagnose — a divide-by-zero in exFAT sync and write paths that runZero notes is implicated in some OTA firmware update processes, an uninitialized-cluster information disclosure path, and a GPT partition-scan loop that can trigger unbounded mount-time denial of service in pre-R0.16 implementations.
Triggering these bugs requires crafted FAT, exFAT, or GPT images, delivered through removable media such as USB drives or SD cards or through update channels that mount media automatically. For the highest-severity vulnerabilities, brief physical access to a device with a removable storage interface is sufficient.
More on vulnerability management:
George V. Hulme
Andy Ellis
Starting Points for Defenders
RunZero's guidance to downstream implementors covers three areas: audit the vendored version of FatFs against the current research findings, audit wrappers and calling code for file-name and file-size handling assumptions, and plan for patch integration from platform maintainers as fixes become available. Beardsley and Moore note that the bugs were found using AI-assisted fuzzing, namely GitHub Copilot applied to the codebase in auto mode, without specialized tooling, and draw the direct implication. The same tools are available to anyone.
For enterprise security teams, the FatFs disclosure surfaces a program-level gap: Current vulnerability management programs were designed around software and do not automatically transfer to embedded firmware. Devices with firmware components need to be tracked, including firmware versions, update mechanisms, and physical access controls, before disclosures force a reactive inventory or leave missing at-risk devices altogether.
“Across the board, organizations need to move from purely scanning and managing the number of vulnerabilities to prioritizing vulnerabilities for remediation and being focused on mitigating vulnerabilities with proven paths of exploit,” Theresa Lanowitz, cybersecurity analyst at research firm Omdia, said.
Beardsley noted that security teams should use SBOMs (software bills of materials) to begin identifying components, open-source and otherwise, present in embedded technology. This aligns with recommendations by CISA and others, Beardsley added.
Lanowitz agreed and added that it is important to insist upon a comprehensive SBOM (Software Bill of Materials), so engineers working with the firmware know the origin of all source code. “This comes down to understanding third-party suppliers as well as those n-party suppliers, who may have been contracted by the original third-party,” she said.
“Knowing your software supply chain, the status of a vulnerability being reachable and exploitable, and the constraints of the hardware environment are critical,” she added.
“Alternatively, defenders can use an LLM-driven vulnerability hunter to audit their firmware packages. This approach will likely uncover bugs but also mask which components are exploitable across implementations,” Bearsdley warned.
“Once those components are identified, the job of finding distinct vulnerabilities can be pursued systematically. The only question is who will be the first to discover them: technology providers (like the FatFs community project), technology assemblers (like the many downstream implementers implicated in these findings), end users (who are ultimately the real, impacted users), or criminal and espionage-motivated attackers,” Beardsley added.
