FatFs Flaw Lets One SD Card Take Over Millions of Devices

Millions of devices read an SD card with one small piece of code called FatFs, and researchers just found seven ways to break it. The worst one hands the whole device to whoever made the card.

FatFs does one small job. It lets a device read and write the FAT and exFAT format, the same format your USB sticks and SD cards use. Almost any gadget with a card slot or a USB port needs something like this, and FatFs is free, tiny, and easy to drop in, so a big part of the industry grabbed it. One person writes it. Thousands of products copy the file into their own gear and ship it.

Here is why one bad card is enough. FatFs is the part a device leans on the second you slide a card in. Break it the wrong way and you are not crashing an app, you are handing control of the device to whatever sits on the card. The affected code has been copied into products for years, and if a gadget runs the kind of small operating system that tiny hardware uses, there is a good chance it runs FatFs too. So this is not one broken product. It is one broken part hiding inside plenty of them.

The worst bug works like this. When you plug a card in, FatFs first works out where the data on it begins. To do that it multiplies two numbers that come off the card itself. That single multiply is the weak spot. This is the actual line inside FatFs where it happens:

1

fasize *= fs->n_fats;

The attacker picks the numbers on the card so that this multiply grows past the largest value it can hold and rolls over to something tiny:

1
2

fasize = 0x80000001;
fasize *= 2;

That should be a huge number. Instead it wraps around to 2. That kind of roll-over has a name, an integer overflow, and this one is tracked as CVE-2026-6682.

From there FatFs has the wrong idea of where the data starts. The attacker drops a fake file entry at that spot, and FatFs reports a fake, huge file size. When the program trusts that size and reads the file:

1

f_read(fp, buf, finfo.fsize, &br);

it pulls that attacker-chosen number of bytes into a buffer built for far less, and runs straight off the end into memory it should never touch. On a small chip with nothing to catch it, that overwrite can become the attacker’s own code, running on your device.

The other six lean on the same trick in different spots. A disk label that is too long spills past the small space set aside for it. A very long filename does the same thing in the extra code that products build around FatFs, and on Zephyr that buffer is only fourteen bytes long, so a crafted name spills right over it and corrupts the part that keeps the device running. Another one quietly scrambles data on a fragmented card, with no crash and no error line, so nobody notices until something starts acting strange. One lets old, deleted content leak back out, so bits of files you thought were long gone can be read again. And a simple divide-by-zero during an update kills the device on the spot and leaves it dead. You do not need to memorize the list. It is the same small part, breaking in the same small ways, over and over.

Now look at where this code actually lives.

• → ArduPilot, the autopilot software that flies a large share of hobby and commercial drones, affected by five of the seven
• → Espressif ESP-IDF, the software for the ESP32 chip that sits in smart plugs, cameras and sensors by the million
• → STMicroelectronics STM32, whose code generator drops the vulnerable buffer size into each project it builds for you, so the flaw ends up in commercial firmware nobody ever wrote down
• → MicroPython, still shipping FatFs R0.13c, a release from October 2018, affected by six of the seven
• → KeystoneHQ Keystone3, a hardware wallet people buy to keep their crypto safe offline, affected by the code-execution bug, with a ready-made attack image already sitting in public

The simplest way in is what you could call the evil SD card. Someone with a few seconds of physical access swaps the card or the stick in a device. The moment it goes in, the device mounts it automatically, and the flaw fires before anyone has pressed a button. Think of a camera with an SD slot, a 3D printer, a shop kiosk, an ATM, a voting machine with a USB reader. Machines a stranger is allowed to walk up to and touch.

Physical access is not the only road in. Plenty of devices pull a firmware image over the internet and hand it straight to FatFs without checking it first. On an update channel that runs over plain HTTP, someone sitting in the middle of that connection can feed the device a malformed image and reach the same flaw from far away. Two of the seven, including the one that bricks the device, sit in that update path.

There is a reason this hits small hardware harder than your laptop. Your computer and your phone move their memory around and lock down the important parts, which usually turns an attack like this into a crash instead of a clean takeover. Those two defenses have names, address space randomization and memory protection. Plenty of small chips have neither. Their memory sits in the exact same spot every time, so what would be a gamble on a laptop becomes a sure thing here. On these devices, getting your hands on it is the same as owning it.

The way these bugs turned up says a lot on its own. Researchers looked at this exact same code back in 2017, by hand, and spent days throwing junk data at it. They found only a few minor bugs, nothing worth publishing. They came back in March 2026 and pointed an ordinary AI coding assistant at it, running on autopilot, with a few plain instructions and no special setup. The AI wrote its own tool to flood the code with broken data until it cracked, a fuzzer, and it walked straight into the bugs the human check had missed nine years before. It also helped show these were the dangerous kind, not just crashes.

Two things sit side by side here. On the day this went public, nobody had seen these bugs used in an attack yet. But the people who found them did not stop at describing the problem, they published working proof, including ready-made booby-trapped card images and a demo that runs the attack from start to finish. No attacks out there so far, and the working method already sitting in the open for anyone who wants it.

And this is not a one-off. More and more, people point AI tools at old, dull code that has sat untouched for years, and the AI keeps finding holes that humans walked past. FatFs is one name on a growing list, and it will not be the last.

The harder part is what happens next. FatFs has no security list, no alert system, no way to warn the thousands of products that copied it. The researchers tried more than once to reach the developer, and even pulled in a national coordination center to help make contact. Nothing came back. So they went public and aimed the warning at the only people who can still act, the companies that build on this code. None of the seven was even rated critical, and the worst scores a 7.6 out of ten. That reads as mild, until you remember these run on chips with nothing to soften the blow. Only one of the seven bugs has a proper fix in the latest version, R0.16, the one that made devices hang on boot. That same version puts a partial guard on the bricker bug too. Its mount check can turn the crafted card away before the damage is done, but the math error underneath is still there. The rest are left to each company to find and patch on their own, and that is expected to take years, not weeks. This has happened before with other buried code, and years later those fixes are still trickling out.

If you build firmware, this one is yours to own. Pull the latest ff.c, check which of the seven apply to how you use it, and move to R0.16 for the partition-table fix. The bigger habit is to stop trusting the card. Validate a filesystem image before you mount it, cap the label and filename lengths in your own wrapper code, and never hand an unverified update image straight to FatFs. If you want to check whether a firmware dump even mentions this library, you can look for leftover version strings:

1
2

strings firmware.bin | grep -i "FatFs"
strings firmware.bin | grep -Eo "R0\.[0-9]+[a-z]?"

The second line pulls the version string, if one is there. A hit tells you the version, and anything before R0.16 is missing even the single upstream fix. This only works when the builder left that text in the binary, and no hit does not mean FatFs is absent, since the version often gets stripped during the build.

You cannot patch this one yourself, so the only thing you control is access. Do not plug unknown SD cards or USB sticks into devices that mount them the second they go in, and treat any open card slot on a public machine as a way inside. For a hardware wallet, use only storage you control, and update it only from the maker’s official channel. And take physical access seriously, because a device a stranger can touch for a moment is a device a stranger can take over.

This is the sort of thing I break down in my ethical hacking course, how devices read data, where the trust goes wrong, and how attackers turn a small mistake into full control: → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources: runZero | runZero Research