AI reopened a 2017-audited filesystem and found seven bugs your devices can't patch

The fix most people need for the FatFs flaws is not theirs to ship. In early July 2026 the security firm runZero disclosed seven vulnerabilities in FatFs, a compact filesystem library that devices use to read and write FAT and exFAT storage, the layout on most USB sticks and memory cards. That library is baked into firmware on drones, security cameras, industrial controllers, hardware wallets, and much more, all built on real-time operating systems. Six of the seven have no upstream fix, and the sole maintainer did not respond to the researchers. So this is not a patch-and-move-on story. It is a threat-modeling and detection story.

Coverage from The Hacker News and Security Affairs framed this as an embedded-device patch problem. For almost everyone reading, it is not, because you do not control the firmware where this code lives. The useful questions are narrower: where does it run in your fleet, how would an attacker reach it, and how would you know if one did.

What runZero found in FatFs

Seven flaws, spread across the code that parses a volume and handles filenames. Three rate high at CVSS 7.6 and can lead to memory corruption and code execution on affected hardware. One is a medium 6.1, and the last three sit at 4.6. Only the lowest-impact denial-of-service bug, CVE-2026-6684, has a fix upstream, shipped in release R0.16. The other six do not.

The three high-severity bugs matter most. runZero notes that the embedded targets carrying this library usually lack the memory protections a phone or laptop has, no address-space randomization and no hardware memory guards, so a buffer that overflows tends to become reliable code execution rather than a crash. On that class of device, the firm's point was blunt: brief physical access to a machine anyone can touch should not hand over the whole device, but here it does.

Why "no new commits" stopped meaning "no new bugs"

The part of this disclosure that should change how you think about dependencies is how the bugs were found. runZero went back to a FatFs assessment it had run in 2017 and pointed an off-the-shelf coding assistant at the same source, in an automatic mode, with plain prompts. The assistant wrote a fuzzer that turned up flaws the earlier manual review had walked straight past, then showed they could be triggered in practice. Code a skilled human read and cleared eight years ago gave up seven new bugs in days.

That is the real headline for defenders, and no advisory framed it this way: a clean audit in the past is no longer evidence a dependency is safe now. "No new commits" has quietly stopped meaning "no new bugs." The cheap, fast fuzzing that used to need a specialist is available to anyone now, including the people writing exploits, which is the shift we flagged when Washington put export controls on an AI good at finding bugs. Old, stable, widely embedded code is the softest target precisely because everyone assumed it was settled. Expect more disclosures like this against libraries that have not changed in years.

The patch you want is not yours to ship

FatFs is maintained by one developer. runZero says it tried repeatedly to reach that person and looped in Japan's national coordination center, JPCERT/CC, early on, and got no answer. There is no coordinated upstream fix for the six memory and logic bugs. That inverts the normal patch flow. Usually you wait for a vendor release and deploy it. Here the fix, if it comes at all, has to be written and carried by every downstream project that copied the library into its own tree.

And the downstream reach is large. runZero lists mainstream platforms that bundle it, among them Espressif's ESP-IDF, STMicroelectronics' STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung's TizenRT, and the SWUpdate updater. Each of those, and every product built on them, now owns the patch decision on its own, and many keep local modifications that change how the flaws present. This is the same structural problem we saw when a Node dependency fix could not reach most of the apps that shipped it: the fix exists in a place disconnected from where the code runs. Public proof-of-concept images already sit in runZero's repository, so the exploitation research is done and shared while the fixes are not.

Physical access is the obvious way in. Firmware updates are the quiet one.

The headline vector is removable media. An attacker who can get a rigged USB stick or SD card into a device, a camera with a card slot, a kiosk, an ATM, a voting machine, triggers the parser on mount and, on an unprotected target, runs code. That threat is real for anything the public can touch, and it is why physical-access assumptions on embedded gear need a fresh look.

The quieter path deserves more of your attention. runZero says two of the flaws, the FAT32 integer overflow and the exFAT divide-by-zero, are implicated in some over-the-air firmware update processes, where a device automatically mounts a crafted update image. That detail changes the risk math. If your update channel does not cryptographically verify an image before mounting it, an unsigned or tampered update turns a "needs hands on the device" bug into a remotely triggerable one. The single most useful thing many teams can do here has nothing to do with FatFs: sign and verify your firmware update path, because that is what decides whether these bugs stay physical or go remote.

Treat FatFs as an inventory-and-detection problem

You cannot patch what you cannot reach, so the work is knowing where the exposure lives and catching the second stage if it fires. Four things, in order:

• Inventory the exposure. Find the embedded and IoT devices on your network that run a real-time OS with FAT or exFAT storage: cameras, controllers, drones, kiosks, single-board gear. Ask vendors whether their firmware bundles FatFs and which version. This is the same vulnerability-detection discipline you apply to servers, pointed at the devices most inventories skip.
• Harden the two reachable channels. Restrict physical and removable-media access to devices the public can touch, and require signed, verified firmware images on every update path so the two update-triggerable bugs stay out of reach.
• Watch the second stage, not the overflow. The memory corruption itself happens inside a device with no logs you will ever see, so a network sensor cannot catch it. What it can catch is what comes next: a jailbroken camera or controller beaconing out, scanning, or pivoting into the rest of your network. That is a threat-hunting and detection problem, and it is where a managed detection service earns its keep, by treating a quiet embedded device that suddenly behaves like a foothold as an alert, not noise.
• Assume you carry this for years. With one unresponsive maintainer and dozens of downstream forks, there is no date by which this is "fixed." Fold the exposure into your standing threat model the way you already treat old, unpatchable gear you cannot rip out yet, like the edge devices that turned a patch backlog into an INC ransomware incident.

The instinct on a seven-CVE disclosure is to find the patch and move on. Here there is no patch to find for six of them, and the way in for most attackers is a card slot or an unsigned update, not a network port. The teams that come out of this well are the ones that already know which of their devices run this code and are watching those devices for the moment one stops being theirs.