What happened (quick and slightly alarming)

Security researchers disclosed a batch of vulnerabilities in FatFs, a tiny C library that many embedded devices use to read and write FAT and exFAT media like USB sticks and SD cards. Think cameras, drones, routers, crypto wallets, industrial controllers — if it plugs into removable storage, there’s a decent chance it runs this code.

In the worst case, a booby-trapped USB drive or a malicious firmware image can trick FatFs into doing bad math and then tripping over memory it shouldn’t touch. On devices with weak or no runtime memory protections, that can become memory corruption and, in some setups, full code execution. Yikes.

The seven bugs (short, punchy roster)

Researchers ranked the issues from High to Medium severity. Here’s the lineup — CVE numbers and the short version of what each one does.

  • CVE-2026-6682 (7.6, High): An integer overflow during the FAT32 mount process that can lead to a bogus file size and then memory corruption — exploitable from malformed firmware images as well as physical media.
  • CVE-2026-6687 (7.6, High): An exFAT label field can overflow a tiny buffer, providing a neat foothold for memory corruption.
  • CVE-2026-6688 (7.6, High): Long filenames overflowing wrapper code — many projects copy filename fields into fixed buffers and that wrapper can be the real weak link.
  • CVE-2026-6685 (6.1, Medium): A math wrap in the cache logic on fragmented volumes that can silently corrupt stored data.
  • CVE-2026-6683 (4.6, Medium): An exFAT divide-by-zero that crashes the device; in firmware update flows it could brick hardware.
  • CVE-2026-6686 (4.6, Medium): Files extended past their real end can leak leftover contents from previously deleted files.
  • CVE-2026-6684 (4.6, Medium): A malformed GPT partition table can hang a device during mount. This is the one fixed upstream in the latest FatFs release.

To make things spicier, the researchers published proof-of-concept disk images and a QEMU-based example showing how a real exploit could work. So the technical recipes exist in the wild.

Why this matters and what you should do

Two big reasons this is messy: FatFs is everywhere, and the project is maintained by a very small team with no fast, obvious security pipeline. That means vendors often bundle a copy into their firmware and forget to track fixes. When an upstream maintainer is unreachable, patches don’t propagate automatically.

If you build firmware that touches FAT/exFAT media, do these things now:

  • Locate the copy of FatFs inside your product and note its version.
  • Audit any wrapper code that copies filenames or handles reported file sizes — those wrappers are where many overflows happen.
  • Reject or sandbox untrusted media and update files. Treat USB and SD slots like attack surfaces.
  • Push vendors and platform maintainers (ESP-IDF, STM32Cube, Zephyr, MicroPython, RTOSes, etc.) to provide patched builds if they bundle FatFs.
  • Monitor for firmware updates and apply them in a controlled way — in some cases an update file itself could trigger problems.

In short: don’t assume a USB stick is harmless. Limit who can plug things in, pay attention to updates, and treat removable media like a potential security incident until you’ve audited the code that parses it.

And finally — why does this pattern repeat? Modern fuzzers and even AI-assisted pipelines can now find subtle memory issues that human reviewers miss. When libraries are tiny, widely embedded, and lightly maintained, bugs discovered by researchers (who responsibly try to coordinate fixes) can still sit in shipping products for years unless downstream vendors make patching a priority.

If you’re responsible for devices in the field: keep an eye on vendor advisories, hunt for bundled copies of FatFs in your supply chain, and assume many devices currently read untrusted storage with code that hasn’t been fully secured.