Security firm runZero disclosed seven vulnerabilities in FatFs, a small open-source library that lets devices read and write the FAT and exFAT formats used on USB drives and SD cards. The flaws matter because FatFs is nearly everywhere: it ships inside the firmware of security cameras, drones, industrial controllers, hardware crypto wallets, and countless other gadgets built on real-time operating systems. On the worst-affected devices, an attacker who gets a rigged USB stick, SD card, or update file onto the hardware can corrupt its memory and run their own code.
- runZero disclosed seven vulnerabilities in FatFs, the library devices use to read FAT and exFAT storage.
- FatFs is embedded in firmware across cameras, drones, industrial controllers, and hardware wallets running real-time operating systems.
- The worst flaws allow memory corruption and code execution from a malformed USB drive, SD card, or update file.
- The attack often needs only physical insertion of storage, so a plugged-in drive is the whole exploit.
Why does a tiny filesystem library matter so much?
Because ubiquity is the vulnerability. FatFs is beloved by embedded developers precisely because it is small, portable, and free, which is why it ended up inside a staggering range of devices. FAT and exFAT are the lingua franca of removable storage, so almost anything that accepts a USB stick or SD card needs code to parse those formats, and for enormous numbers of real-time-operating-system devices that code is FatFs. A single library flaw therefore is not one product's problem. It is a shared weakness sitting under cameras on factory floors, drones in the field, controllers in critical infrastructure, and wallets holding private keys. The blast radius is defined by how many things quietly bundle the same code, and here that number is very large.
RelatedKemp LoadMaster Bug (CVSS 9.6) Under Active Attack
What can an attacker actually do?
The mechanics are old but effective. A filesystem is a structured set of data describing where files live, how big they are, and how they link together. A parser reading that structure trusts it to be well-formed. These vulnerabilities exploit that trust: a deliberately malformed FAT or exFAT structure, sizes that overflow, links that point where they should not, feeds the parser values it never expected, corrupting memory. On constrained embedded devices without the memory protections a modern PC has, that corruption can be steered into running attacker-supplied code. From there the attacker has whatever access the firmware has, which on a camera, controller, or wallet is often total.
| Device class | Why it uses FatFs | Worst-case impact |
|---|---|---|
| Security cameras | SD card recording | Firmware takeover, surveillance |
| Drones | SD storage for footage | Control-plane compromise |
| Industrial controllers | USB config and updates | Process disruption, pivot point |
| Hardware wallets | Firmware update media | Key exposure, theft |
| Consumer gadgets | USB and SD media | Persistent malware |
How worried should you be?
It depends on exposure, and honesty matters here. Many of these attacks need physical access to insert media, which is a meaningful barrier for a locked server room and no barrier at all for a camera on a pole, a kiosk in a lobby, or a wallet handed a malicious update file. The scenarios that should worry defenders are the ones where untrusted media reaches a device routinely: field-deployed hardware, shared kiosks, supply-chain update files, and any device whose USB or SD slot the public can reach. The uncomfortable truth is that plenty of embedded gear is built on the assumption that whatever gets plugged in is friendly, and that assumption is exactly what these flaws break.
What is the fix, and why is it slow?
The library maintainer can patch FatFs, and updated code addresses the disclosed issues. The hard part is distribution. A vulnerability in a widely embedded library only gets fixed on your device when the device maker pulls the patched library, rebuilds firmware, and ships an update, and then only if you install it. Much embedded hardware is rarely or never updated: it has no auto-update, the vendor has moved on, or the device sits in a location nobody touches for years. So the patch existing and the patch reaching devices are very different milestones, and the gap between them is measured in years for a lot of this gear. This is the structural weakness of the embedded world, and every shared-library disclosure exposes it again.
RelatedSharePoint RCE Flaw Is Under Active Attack, CISA Warns
- NowInventory FatFs exposure. Identify devices that mount USB or SD media and run an RTOS.
- NowRestrict untrusted media. Treat unknown USB drives and SD cards as hostile; lock physical ports where you can.
- DaysChase vendor firmware. Ask each device maker for a FatFs-patched build and a timeline.
- OngoingPatch and verify. Deploy updated firmware and confirm the library version actually changed.
Our take
FatFs is a reminder that the software supply chain is not just npm packages and cloud dependencies. It is also the tiny, decades-old libraries welded into the firmware of physical objects nobody thinks of as computers. Seven bugs in one small filesystem library ripple out to cameras, drones, controllers, and wallets because they all quietly share the same code, and most of them will never be patched, not because a fix is unavailable but because the machinery to deliver it does not exist. The practical defense is boring and effective: treat every unknown USB stick and SD card as a loaded weapon, lock down the ports on anything exposed, and pressure vendors for updates. The deeper lesson is that ubiquity plus un-updatable equals permanent risk, and the embedded world is full of both.
- DisclosurerunZero Research the FatFs vulnerability write-up
- ReferenceFatFs project library source and updates
- OfficialCISA KEV catalog track active exploitation
Original analysis by GenZTech. Source: runZero. Figures current as of July 2026.