Plug In a USB Stick, Own the Device – the FatFs Flaw

Thu, 09 Jul 2026 00:00:00 +0200

It was one of those moments where I stop mid-scroll through the news feed. A headline, half technical, half sensational – and a gut feeling that instantly says: Oh no. I’m going to have to make a video about this again.

The story: security researchers had found seven flaws in a piece of software most people have never heard of. The name sounded harmless – FatFs. But the deeper I read, the clearer it became: this isn’t some niche topic for firmware nerds. This tiny piece of code sits inside millions of devices. Very likely in your home, too. And the way these flaws were found honestly gave me goosebumps.

So: grabbed a tea, opened the research doc, set up the camera. Here’s the whole story.

To load the video, please click the image. Please note that by doing so, data will be transmitted to YouTube.

The nightmare in one sentence

Imagine someone plugs an ordinary USB stick into your device. They don’t type anything, don’t open a file, don’t crack a password or bypass a firewall. They just plug it in. And in that very moment, the device no longer belongs to you – it belongs to them.

That’s exactly what the most dangerous of these flaws makes possible. No sophisticated network attack, no stolen password – a rigged storage medium is enough. And the crazy part: the code that makes this possible is probably running in a device in your home right now.

What even is FatFs?

FatFs is a free, platform-independent software module written in C. Its only job: to teach a device how to read and write FAT- and exFAT-formatted USB sticks and SD cards.

Sounds trivial. But it’s exactly what you need when a device doesn’t have a full operating system like your laptop does. Your security camera, your ESP32 hobby project, an industrial controller, a drone – none of these have a Windows or Linux kernel to read the USB stick for them. They need a small, lean driver that handles exactly that. And very often that driver is FatFs.

Because FatFs is so small, so free, and so reliable, it’s baked into the base kits (SDKs) that countless devices build upon – not just hobby projects, but finished products sold in the millions worldwide. A tiny building block with a gigantic reach.

The sore spot: maintained by a single person

And here’s the first part that gives you pause. FatFs is essentially maintained by one single person – the Japanese developer known by the handle “ChaN”. No security team. No security mailing list. No vulnerability reporting channel. No CVE history.

One person, as a volunteer, looks after code that runs in millions of devices. That’s not a criticism of that person – on the contrary, it’s an admirable contribution to the common good. But it’s the core of the problem we’re about to hit. (If you want the pattern behind this: it’s exactly the kind of “lonely dependency in the foundation” that xkcd nailed in a legendary 2020 comic.)

The most dangerous flaw: CVE-2026-6682

Each of these vulnerabilities gets a unique ID and a severity score – a number between 0 and 10. The worst of the seven is CVE-2026-6682, rated “high” with a CVSS score of 7.6.

What happens technically? Here it is, without the jargon:

When your device reads a memory card, it blindly trusts the size values stored on the medium for each file. It does its math with those numbers to find its way around the card – which file sits where, how long it is, where to read.

Now the attacker writes completely absurd numbers onto a manipulated SD card. The device does its math with them anyway, because it trusts the card. And in doing so, the calculation overflows – a so-called integer overflow. A bit like an old odometer rolling over from 9,999 back to 0. Except here it’s not the counter that breaks – the device suddenly starts writing to a completely wrong location in memory.

And that’s exactly what an attacker can exploit to inject their own malicious code. The researchers at runZero put it bluntly:

“Every physical access is a jailbreak.”

Why does this work so reliably? Because small IoT devices almost never have the protections your PC has long had: no random shuffling of memory addresses (ASLR), often no real memory protection. What would fail at several hurdles on a modern PC sails right through on a bare microcontroller.

Not just one flaw – seven

CVE-2026-6682 is the most spectacular, but it doesn’t come alone. There are seven vulnerabilities in total (CVE-2026-6682 through -6688), and three of them have code-execution potential:

CVE	Short description	Impact
6682 ⭐	Integer overflow on FAT32 mount	Code execution (RCE), CVSS 7.6
6683	Division by zero (exFAT)	Crash / denial of service
6684	Infinite loop on partition scan	Device hangs on mount
6685	Integer underflow in cache	Silent data corruption
6686	Uninitialized memory after seek	Old, deleted data readable
6687	Stack overflow via exFAT label	Code execution (esp. STM32)
6688	Overflow via long filename	Code execution

The common denominator across all seven: FatFs blindly trusts the metadata on the storage medium – file size, label length, partition count – and does its math with it without ever checking whether the values are even plausible.

How big is the blast radius?

Now the key question: does this even affect me?

Among the affected projects is Espressif’s ESP-IDF – the development foundation for the famous ESP32 chips. And if you know my channel, you know these chips are everywhere. In ESPHome devices, in Shellys, in countless hobby projects – but also in masses of commercial off-the-shelf products. I’ve already made several videos about ESP security flaws, and it just doesn’t stop.

The researchers verified 17 concrete projects that contain vulnerable FatFs code:

espressif/esp-idf (ESP32) – the basis of ESPHome, Tasmota, Shelly & co.
STM32Cube – in countless industrial and consumer devices
Zephyr RTOS and MicroPython – growing IoT platforms
ArduPilot – flight control for drones
Keystone3 – a hardware crypto wallet (this is about real money)
Samsung TizenRT, RT-Thread, Mbed, RIOT, NodeMCU and more

Explicitly named as an attack target: security cameras with an SD card slot. Exactly the kind of camera many of us have hanging by the front door, in the garage, or in the stairwell.

And here’s the truly insidious part: you can’t even easily check whether your specific device is affected. Because which manufacturer writes on the box which filesystem driver they’ve buried deep in their firmware? Nobody does. So the honest rule of thumb is: if you own an embedded device with an SD card or USB slot, assume in case of doubt that it could be affected.

The real twist: an AI found the flaws

Now comes the part that made me want to do this video in the first place. Because how these flaws were found is almost more interesting than the flaws themselves.

These same researchers had already looked at FatFs once before – back in 2017. Back then they combed through the code by hand with human experts and fuzzed it for days. The result: a few minor bugs. Nothing earth-shattering.

Now, in early 2026 – almost ten years later – they look at the same code again. But this time with a new helper: GitHub Copilot, an AI coding assistant of the kind developers now use by the millions every day. No specialized attack framework, no elaborate fuzzing pipeline. The plain default mode in VS Code, with a few simple prompts.

And suddenly out tumbled flaws that nobody had seen in 2017 – even though the vulnerable code already existed back then. An off-the-shelf AI with a few simple prompts uncovered it within days.

The researchers’ sentence that gave me goosebumps:

“If we can uncover issues like these through the thoughtful use of AI-assisted vulnerability research, then just about anyone else can too.”

And that is the real story. Here it’s the good guys who used the tool – and who reported their findings responsibly. But we have to assume that just as many others are doing the exact same thing right now. And they most certainly don’t publish their findings.

The barrier to finding flaws in the “long tail” of old, long-overlooked code has just collapsed. For defenders and attackers alike.

The second shock: there’s no patch

“Alright,” you might think, “then an update will come and it’s sorted.” And that’s exactly where the next problem lies.

Remember the one-man project? The researchers contacted the maintainer back in March 2026, several times since. They even brought in JPCERT/CC – Japan’s coordination center for security vulnerabilities. The response to date: radio silence.

That means there’s no central patch to simply roll out. Every single project that builds on FatFs – ESP-IDF, Zephyr, STM32Cube, MicroPython and all the rest – now has to find the flaws itself, fix them itself, and then ship the updates to its own devices. And the manufacturers of those devices in turn have to follow suit.

The researchers therefore estimate the window until widespread remediation in years, not days or weeks.

Staying honest: the “physical access” fallacy

And now let’s take a breath. Because here comes the part many sensational headlines leave out – and where most people make a thinking error.

This attack requires physical access. The manipulated card or stick actually has to be plugged into the device. This is explicitly not the “a hacker breaks into your camera from the internet tonight” scenario. If a device sits safely in your home and no stranger can reach it, such a jailbreak isn’t a catastrophe.

There’s even a fair objection I keep reading in the comments on other reports: for “locked-down” devices you own yourself, being able to jailbreak them via USB is arguably more of a feature than a threat. There’s something to that.

But – and here’s the thinking error – there very much are situations where this hits you hard:

Used devices. You buy a camera or hobby device secondhand and don’t know what’s on the included memory card.
Cameras in accessible spots. Doorbell, garage, stairwell, office building – anywhere someone could quickly swap an SD card.
The unattended moment. A cleaner, a technician, a visitor. A few seconds of physical access is enough. In security this is called “evil maid”.
The supply chain. Rigged storage media that arrive already manipulated.

So this isn’t an apocalyptic scenario. It’s about realistically assessing your own threat model – instead of panicking or reflexively dismissing the whole thing.

Your smart home survival tips

You can barely verify whether a device is affected. But you’re not powerless:

Install updates. I say it in every other video – but that’s exactly what updates are for. As soon as Espressif, ESPHome or your camera manufacturer follows up: install, don’t dismiss.
Think about which devices strangers can reach. Not every device is equally exposed. The camera on the outside wall is a different risk than the sensor in your living room.
Always reset and reflash used devices before letting them into your network. You never know what the previous owner left on them.

The real lesson

In the end, this one flaw isn’t the big story. FatFs will get fixed, sooner or later. The real lesson is a different one:

AI has driven the cost of finding bugs like these to near zero. Code that flew under the radar for ten years is now uncovered in days – by off-the-shelf tools anyone can use. That’s good news when the good guys are faster. And unsettling news when they’re not.

Over the coming years we’ll see a lot more reports like this. That’s exactly why this video mattered so much to me.

Sources & further reading

runZero – original report: Seven FatFs bugs, one very large blast radius
runZero – research repo with PoC & details: vulns-2026-fatfs-chance
Risky Business: FatFs bugs enable physical access attacks on a load of devices
FatFs – official project page: elm-chan.org/fsw/ff

More on the blog

ESPHome security flaw: critical CVE hits all ESP32 devices

Do you find AI hunting for security flaws more reassuring or more unsettling? Let me know in the comments – I’m curious about your take.

Note: Links marked with affiliate link are affiliate links. As an Amazon Associate I earn from qualifying purchases. This means I receive a small commission if you purchase through these links — at no extra cost to you. The revenue helps me run this blog and YouTube channel and keep creating content. Thank you for your support!
― Joachim

FatFs on Smart Home? Sure — But Secure!

Plug In a USB Stick, Own the Device – the FatFs Flaw

The nightmare in one sentence

What even is FatFs?

The sore spot: maintained by a single person

The most dangerous flaw: CVE-2026-6682

Not just one flaw – seven

How big is the blast radius?

The real twist: an AI found the flaws

The second shock: there’s no patch

Staying honest: the “physical access” fallacy

Your smart home survival tips

The real lesson

Sources & further reading

More on the blog