Fats in the open: seven vulnerabilities that expose cameras, ATMs and drones

The RunZero security firm has recently revealed a battery of seven vulnerabilities in FatFs, the light C library that interprets and handles FAT and exFAT volumes on thousands of embedded devices. Although the name may sound technical, the involvement is direct: This affects cameras, ATMs, public kiosks, drones, industrial controllers and hardware forks, devices that often accept SD cards or penders and run firmware with few or no modern memory defenses.

Among the outstanding failures are an entire overflow (CVE-2026-6682) that can produce a false reading length and lead to memory corruption and code execution, and errors in the management of label fields and long names in exFAT that allow to obtain a support point for exploitation. RunZero qualifies the vulnerabilities between Media and High Gravity and recalls that many are exploitable by a malicious physical medium or a manipulated update file. Only one of the seven is corrected in the official upstream (a problem block that used to hang with malformed GPT tables), leaving most of the risk in the hands of integrators and manufacturers.

The practical problem is software governance: FatFs is essentially maintained by a single developer and there is no robust outreach channel, security list or consolidated response when a failure is detected. That turns the correction into a puzzle that often ends up in ad hoc patches in each SDK and product that incorporates the library. The result is a long exposure window on devices already deployed, similar to previous incidents where firms and suppliers took years to distribute corrections.

There is another relevant reading: vulnerabilities were not only discovered by manual inspection, but also with the help of a flow of IA tools for fuzzing that built runZero. This automated approach led to the finding of failures that a previous audit did not detect. This shows that fuzzing techniques assisted by automated models and agents are already able to find exploitable vectors with little effort, so keeping vulnerabilities quiet no longer protects anyone.

For firmware developers and product managers the priority is immediate: to locate the copy of FatFs that is embedded in their toolchain and to evaluate the code that wraps calls to the library. It is not enough to update a unit; it is necessary to review how file names, label fields and sizes reported by the library are managed, and apply strict validation of limits before any strcpy, memmove or reading based on a size that comes from the file system. It is also appropriate to compile with memory mitigation (e.g. battery protection, ASLR / DEP if RTOS supports it, -fstack-protector, fortify) and to add controls in running time to detect abnormal readings.

If you manage already deployed devices you must assume that physical ports and update channels are risk vectors. Limit physical access, disable the self-mounted if possible, require authentication and signature for firmware updates, and monitor the log and peripheral behavior after media insertions. In critical environments, imposing physical controls (slot blocking, monitoring) and operational policies on who and how it can connect removable means reduces the likelihood of exploitation.

At the coordinated level, industry should demand best practices in critical libraries: sustained maintenance, public safety lists, and patch response and delivery processes to downstream projects. Meanwhile, integrators should treat libraries such as FatFs as high-risk components and plan continuous safety tests, including directed fuzzing and review of the "wrappers" that each product implements around FatFs, because many vulnerabilities come from auxiliary code, not from the bookstore per se.

For further information, read the runZero note and the original FatFs documentation, and take as a reference safety guides for IoT devices. The RunZero report explains techniques and provides concept evidence, and the FatFs project page provides context for maintenance and versions. The report of RunZero and the FatFs page ( ChaN - FatFs) are useful starting points. It is also recommended to review community resources on IoT security to guide operational and design mitigation, such as the OWASP project for connected devices: OWASP IoT Project.

In short, these FatFs failures remember that the security of the embedded software supply chain is as weak as its less well-served link. If your product touches FAT / exFAT: identify, audit, park and mitigate; if your organization operates devices: reduce the physical attack surface and require signatures and controls in the updates. The real-estate window can be closed only if manufacturers, maintainers and operators act quickly and transparently.