Security research firm runZero disclosed seven previously undisclosed vulnerabilities in FatFs, a widely embedded open-source filesystem library found in hundreds of millions of devices including IP cameras, commercial drones, consumer IoT devices, hardware cryptocurrency wallets, and industrial control systems. None of the seven vulnerabilities have patches available at the time of disclosure.
The Seven Vulnerability Classes in FatFs’ Filesystem Parsing
FatFs is a compact, portable filesystem library designed for resource-constrained embedded devices that need to read and write FAT filesystem volumes. Its wide adoption across device categories from industrial automation equipment to consumer electronics makes it a single point of vulnerability across a remarkably diverse set of hardware targets.
runZero’s disclosure identifies seven flaws across multiple vulnerability classes in how FatFs processes FAT filesystem images. The classes include memory corruption, out-of-bounds read and write operations, and integer overflow flaws — vulnerabilities that arise when FatFs encounters malicious or malformed filesystem structures that it was not designed to safely reject. The attack premise is straightforward: provide a device that uses FatFs with a specially crafted storage medium, and the filesystem parsing code triggers the underlying flaw.
Memory Corruption and Out-of-Bounds Flaws in FatFs Malformed Image Parsing
Memory corruption and OOB vulnerabilities in filesystem parsing code are particularly concerning because filesystem libraries are typically trusted software that operates close to hardware with privileged access to device resources. A memory corruption flaw in FatFs can potentially allow an attacker who controls the content of a mounted storage device to achieve arbitrary code execution on the device’s processor — the severity of that outcome depends on the specific device’s architecture and what controls separate the FatFs code from sensitive device functions.
Out-of-bounds read flaws expose memory contents adjacent to the filesystem parser’s allocated buffers, potentially leaking sensitive data that resides in the device’s memory. On a hardware cryptocurrency wallet where private key material may reside in memory during active operation, an OOB read triggered through a malicious storage interaction carries specific risks that go beyond a generic embedded device information disclosure.
Hardware Cryptocurrency Wallet Exposure Through FatFs Storage Layer Flaws
The hardware cryptocurrency wallet category is the most financially sensitive device class affected. Many hardware wallets use FatFs to manage their internal storage filesystem. A vulnerability exploitable through the storage layer could potentially bypass the wallet’s security perimeter — the boundary between the general processing environment and the secure element or secure enclave where private key material is held.
If an attacker can supply a malicious filesystem image to a hardware wallet’s FatFs instance — through a specially crafted firmware update process, a malicious SD card if the device accepts one, or another storage-adjacent interaction — the resulting code execution or memory read could potentially reach key material that the wallet’s physical security design was intended to protect from software-based attack.
Why Firmware-Embedded Libraries Present a Long-Tail Patching Problem
FatFs’s deployment model makes patching fundamentally different from patching a desktop application or a web server. The library is not installed as a separate package that users can update through an app store or package manager. It is compiled into device firmware at manufacturing time and becomes part of the device’s permanent software unless the device manufacturer issues a firmware update that includes a patched version.
This creates a patching dependency chain: runZero discloses the vulnerability; the FatFs project must issue a patched version of the library; each affected device manufacturer must integrate the patch into their firmware and test it for their specific hardware; and the device owner must receive and apply the manufacturer’s firmware update. At each stage, the chain can break. Manufacturers may not patch quickly, may not prioritize older product lines, or may have discontinued support for devices still in active use. Many embedded devices in deployment never receive firmware updates even when patches exist.
The result is a long-tail exposure scenario similar to the 2021 Ripple20 disclosure, which identified vulnerabilities in a widely embedded TCP/IP library affecting hundreds of millions of devices and found that vendors took years to patch and many devices remain unpatched indefinitely.
Attack Scenarios and the Risk from Malicious Storage Media
The practical attack path against FatFs-vulnerable devices involves providing the device with a malicious storage medium: a crafted SD card, USB drive, or remotely provisioned filesystem image for networked devices. Devices with remote storage provisioning capabilities — network-attached cameras that receive configuration updates, industrial controllers that accept firmware from network shares — have a broader attack surface than devices where malicious storage media requires physical access.
Without patches available from the FatFs project or device manufacturers at the time of runZero’s disclosure, the primary near-term response is operational: restricting physical access to devices that accept removable storage media, disabling unused storage interfaces where possible, and monitoring for unexpected filesystem operations on networked devices in sensitive environments.
