Cybersecurity

One Coder's Filesystem Sits in Millions of Devices

Seven FatFs bugs, six of them unpatched, ship inside cameras, drones, ATMs and crypto wallets via ESP-IDF, STM32Cube and Zephyr. Why owners must audit their device bill of materials.

CybersecurityBy Servola Tech Desk2026-07-054 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

One Coder's Filesystem Sits in Millions of Devices

Key takeaways

Seven newly disclosed flaws in FatFs, a filesystem library maintained by a single unreachable developer, ship inside cameras, drones, industrial controllers, ATMs and crypto wallets, and six of the seven have no upstream fix.
The library reaches devices through mainstream SDKs including Espressif ESP-IDF, STMicroelectronics STM32Cube and Zephyr, so most affected vendors do not yet know they are exposed.
A booby-trapped USB stick, SD card or firmware update file can corrupt device memory and run attacker code, turning brief physical access into full compromise.
runZero published working proof-of-concept exploit material on 1 July, so the barrier to abuse is already low even though no attacks have surfaced yet.
The fix is not a patch you download; it is a bill-of-materials problem your vendors must solve, and you must make them.

A dependency almost nobody can see

On 1 July 2026, security firm runZero disclosed seven vulnerabilities in FatFs, a small library that lets a device read and write the FAT and exFAT formats used on USB drives and SD cards. It is one of those pieces of code that is everywhere and visible to almost no one. It ships in the firmware of security cameras, drones, industrial controllers, hardware crypto wallets, public kiosks, ATMs and voting machines with USB ports.

Three of the flaws are rated high severity. CVE-2026-6682 is an integer overflow when mounting a FAT32 volume; CVE-2026-6687 overflows a buffer through an exFAT volume label; CVE-2026-6688 overflows the wrapper code many products add around FatFs. On real hardware, the worst of these become memory corruption and code execution. The library reaches these products through mainstream toolkits, Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT and the SWUpdate updater, which is precisely why so many vendors will not yet know they are in the blast radius.

Physical access is the point, not the excuse

Some will dismiss this as needing physical access. For the device categories affected, that is the vulnerability, not a mitigation. A security camera, a public kiosk, an ATM, a voting machine: the entire design promise is that a member of the public can touch it, or plug something into it, without compromising it. These bugs break that promise. An attacker with a crafted USB drive, SD card or update file can corrupt memory and run code.

Two of the flaws, the FAT32 overflow and an exFAT divide-by-zero, are also reachable through over-the-air firmware updates. That widens the exposure from someone standing in front of the machine to someone who can influence the update channel, and it means a failed update can brick hardware in the field. runZero has published proof-of-concept disk images, a test harness and a working QEMU-based exploit, so the material an attacker would need is already in the open.

When the fix has no owner

The uncomfortable core of this story is maintenance. FatFs is kept by one developer, and runZero says it tried repeatedly to reach that maintainer and looped in Japan's JPCERT/CC coordination centre, with no response. Only one of the seven bugs, a denial-of-service hang, is fixed upstream in release R0.16. The six memory-corruption issues have no upstream patch, no security mailing list, and no mechanism for the many products that bundle FatFs to learn they are affected.

This is what modern supply-chain risk actually looks like for physical assets. Not a headline breach, but a load-bearing component with a single point of human failure, embedded so deep that the companies shipping it cannot enumerate their own exposure. The discovery method underlines how the balance has shifted: runZero found these using an off-the-shelf AI-assisted fuzzer in March 2026, work that a manual audit years earlier had missed. The tools to find these bugs are now cheap and widely available, which means attackers have them too.

What an owner should demand

You cannot patch your way out of this from the outside, so make it a procurement and vendor-management question. For any fleet of connected or embedded devices, cameras, controllers, kiosks, wallets, ask each vendor a direct question: does your firmware use FatFs, which version, and what is your plan for the six unpatched CVEs? A vendor that cannot answer quickly is telling you something about their own visibility into their code.

Internally, treat physical ports and update channels as live attack surface. Limit who can plug media into exposed devices, and confirm that firmware updates are signed and validated before they are applied. runZero's own guidance to engineering teams, audit your vendored version, audit your wrappers, audit your filename and file-size handling, is the checklist to hand to any vendor who builds hardware for you.

Frequently asked questions

How do we even know if we are affected?

You often cannot tell from the outside, because FatFs is buried inside firmware delivered through SDKs like ESP-IDF, STM32Cube and Zephyr. The practical route is to ask each device vendor whether their firmware includes FatFs and which version, and to treat an unclear answer as a risk in itself.

Is a full remote attack possible, or only with physical access?

Most of the flaws require crafted removable media, so physical access. But two are implicated in over-the-air firmware update flows, which extends the risk to anyone who can influence the update channel and can also brick devices during a failed update.

Will there be an official patch?

Only one of the seven bugs is fixed upstream. The maintainer and Japan's JPCERT/CC did not respond to runZero, so the six memory-corruption issues fall to each downstream vendor to fix independently. That makes your vendors, not the library author, the party you should be pressing.

How urgent is this if no attacks have been seen?

No exploitation has surfaced, but working proof-of-concept exploit material is already public and the flaws were found with widely available AI-assisted tooling. The sensible posture is to open the vendor conversations now, while it is a planning exercise rather than an incident.

The riskiest dependencies are the ones nobody can name and nobody maintains. Map which of your physical devices carry this filesystem, put the question to your vendors in writing, and treat every exposed port as the front door it has just become.

FatFsEmbedded SystemsIoT SecuritySupply ChainrunZeroJPCERT

The Chips Act Resets Your Supply Chain

On 3 June 2026 Brussels proposed Chips Act 2.0. The real signal for European buyers is not subsidies but supply-chain resilience and Strategic Projects.

3 min read1 views

Cybersecurity

A Linux Root Bug Now Hits Servers and Android Phones

CVE-2026-46242, Bad Epoll, lets any local user become root on Linux 6.4+ servers and Android at 99 percent reliability. What owners of Linux fleets should do now.

3 min read

Digital Sovereignty

The EU Council Revived the Rule That Scans Private Messages

The EU Council revived the lapsed rule that lets providers scan private messages with AI. For owners, confidential communication is now a governance choice.

2 min read14 views

← All articles