In July 2026, researchers disclosed seven new CVEs in FatFs by ChaN, the filesystem driver running in a huge share of the world's embedded and IoT devices.
If your product reads SD cards, mounts USB drives, or uses removable media, there's a strong chance FatFs is in your image.
We find out what's in your firmware, whether these CVEs are actually reachable in your product, and what it takes to fix them.
FatFs is not an obscure library. It's likely already in your source code.
FatFs underpins widely used platforms including Espressif ESP-IDF, STM32Cube, Zephyr RTOS, MicroPython, Arduino, RT-Thread, Mbed, Samsung TizenRT, and SWUpdate.
The trigger paths are ordinary product features. These flaws are reachable through crafted FAT, exFAT, or GPT images delivered via removable media or auto-mounted update channels. For embedded targets that have physical access to a USB or SD interface, this can translate directly into a full system compromise.
The maintainer did not respond to the researchers' disclosure attempts, so the burden of auditing, validating, and patching falls on downstream implementers — meaning you.
Three High-severity memory-corruption bugs and four Medium issues. Reachability is what determines your risk.
mount_volume() during FAT32 mount
Attacker-controlled file-size metadata; potential heap/stack overflow and code execution.
f_getlabel()
Oversized writes into caller stack buffers — a clean memory-corruption primitive.
fno.fname values (long filenames enabled)
Overflows fixed-size buffers in downstream callers using strcpy/sprintf. A full fix requires wrapper-level changes.
Stale cache behavior and out-of-bounds effects; risk of silent data corruption.
A reliable crash — particularly concerning during OTA update processes, where it can brick an update in the field.
Leaks stale content from deleted files in shared-media or multi-stage boot environments.
Unbounded partition-scan loops; mount-time denial of service. Is your library earlier than R0.16?
A focused review that tells you where you actually stand, and the remediation to close whatever it finds.
A scoped assessment of one firmware project, answering the questions your team can't answer from memory:
You get a written report: the finding, the reachable-vs-noise triage, a prioritized remediation list, and a short summary a non-specialist manager or a customer's security reviewer can act on.
No FatFs in your firmware? We don't charge you the full fee. If we find no FatFs in the firmware you send, you pay just $399 — and get a documented finding to that effect for your CRA file.
The fixes themselves, at our standard consulting rate:
Leave your email and we'll reach out, that's all we need to start. If you already know your platform or what's prompting this, add a line and we'll come back with something specific.
Real firmware expertise since 2012 — not a scanner running a checklist.
Hands-on embedded firmware work since 2012. We read code, follow the actual data path, and understand what a filesystem driver is doing on a constrained target — not just what a scanner flags.
Vendored, locally modified, poorly documented FatFs copies are the norm. That's exactly the kind of code we specialize in — the work nobody left on your team can do.
We tell you what's actually reachable in your product, so you fix what matters and ignore the rest. The triage is the value.
From "is this in our image?" to a shippable, patched build. If the firmware can no longer be rebuilt, our MCU Rescue practice resurrects the build first.
US-based and familiar with medical and industrial compliance contexts, so findings land in terms your regulatory and customer reviewers can act on.
This is engineering-led identification of security exposure and risk, not a legal determination of compliance obligations. Where a finding turns into a regulatory or contractual question, we flag it and recommend confirming with appropriate counsel.
Want a broader look than one library? That's a firmware audit. Can't rebuild the firmware to patch it at all? Start with MCU Rescue or Build Vault.
Source: runZero disclosure, reported by Cyber Security News, July 2026. CVE identifiers and CVSS scores are as published in that disclosure and are verified against NVD before they drive remediation decisions.