Somewhere in a warehouse right now, a security camera is reading a firmware update off a microSD card. The camera doesn’t know who wrote the code that parses that card. Neither does the installer who mounted it, the integrator who sold it, or the facilities manager who approved the purchase order. The code was written back in 2006 by a single engineer in Japan, dropped into a library called FatFs, and quietly copied into more embedded devices than anyone has bothered to count. This week, security firm runZero gave everyone a reason to start counting: seven vulnerabilities, all unpatched at disclosure, sitting inside that library. This is the kind of cybersecurity story that doesn’t involve a nation-state or a zero-day bidding war. It’s just a small piece of code nobody remembers agreeing to trust.

The Library Nobody Owns

FatFs exists to solve a boring problem: letting a device read and write FAT and exFAT, the formats used on nearly every USB drive and SD card ever sold. It’s small, free, and portable enough to drop into almost any microcontroller. That’s exactly why it ended up inside security cameras, drones, industrial controllers, and hardware crypto wallets. Nobody markets a product by saying “now with FatFs inside.” It’s invisible plumbing, the kind of dependency that gets pulled into a build once and then never revisited, because revisiting it would mean someone has to remember it’s there.

That’s the actual finding here, more than any single CVE number. Embedded vendors build products on stacks of third-party code they didn’t write and often can’t fully audit, then ship that stack into environments with no update mechanism worth the name. A camera bought in 2019 is still running whatever version of FatFs shipped that year, because nobody at the vendor is tracking library versions across a decade of SKUs, and nobody at the customer site is checking firmware changelogs for filesystem parsing bugs. Software supply chain risk usually gets discussed in terms of npm packages and CI pipelines. Embedded firmware is the older, quieter version of the same problem, and it’s had far less scrutiny.

Why a Filesystem Bug Is an Attack Surface

The seven flaws runZero disclosed live in the code that parses FAT and exFAT metadata: things like directory entries, file allocation tables, and volume labels. Parsing untrusted, attacker-controlled structures is exactly where memory corruption bugs live, and a malicious USB drive or SD card is about as close to a free initial-access vector as it gets in physical security testing. Drop a corrupted card near a drone operator, a facility using badge-cloning hardware, or an industrial site that swaps SD cards between PLCs, and you have a delivery mechanism that doesn’t touch a network at all.

What makes this worse than a typical desktop vulnerability is the response gap. On a laptop, a patched FAT parser ships through Patch Tuesday and most machines get it within weeks. On an embedded controller running a proprietary real-time OS with a five-year product lifecycle and no remote update path, a filesystem bug can outlive the device. Vendors that license FatFs as a component rarely have a fast path to rebuild, retest, and redistribute firmware across every product line that uses it, and plenty of these devices are physically inaccessible once deployed, bolted to a ceiling or buried in a control cabinet.

Hardening What You Can’t Patch

Waiting for a firmware update from a vendor who may never ship one isn’t a strategy. Defense in depth for embedded devices means assuming the firmware itself is a liability and building controls around it instead of inside it. A few things actually move the needle here. First, inventory: know which of your cameras, sensors, drones, and controllers accept removable media at all, because that’s your actual exposed attack surface, not the ones that don’t. Second, physically restrict media access where the device’s role doesn’t require it. If nobody needs to swap an SD card in a lobby camera, disable or lock down the slot.

Network segmentation matters just as much here as it does anywhere else. Embedded devices with unpatched, unauditable firmware belong on isolated VLANs with tightly scoped east-west rules, not sitting on the same segment as domain controllers. Threat detection at the network layer should watch for these devices doing anything outside their normal traffic pattern; a camera that suddenly starts scanning its subnet or reaching out to unfamiliar hosts is a stronger signal than any log the device itself will ever produce, since most of this hardware has no meaningful local logging to speak of. Pair that with brute-force protection on any management interface these devices expose. Tools like IPBan Pro exist precisely for the gap between “this device has weak defenses” and “I can’t rebuild its firmware,” blocking repeated unauthorized access attempts at the network edge while you work the longer-term problem.

Incident response planning for embedded fleets also needs a different assumption than IT infrastructure does: you may not be able to patch, only isolate. Build the runbook now, before a compromised camera or controller shows up mid-investigation, so the answer to “what do we do with the device we can’t fix” isn’t improvised on the spot.

The Bigger Bill Comes Due Later

None of this makes FatFs a bad piece of code. It did exactly what it was built to do for two decades, and the fact that it’s everywhere is a testament to how well it worked. The real lesson is about what happens after code like this succeeds: it disappears into products, outlives its original context, and becomes someone else’s unmanaged risk years later. Security hardening for embedded environments has to start from the premise that the firmware inside your devices is older, less visible, and less accountable than anything running on your servers, and that the vendor relationship you signed up for probably didn’t include a plan for this moment.

Sources

• Unpatched Flaws Disclosed in Filesystem Bundled Into Millions of Embedded Devices