Seven out of seven vulnerabilities without patches in software for drones, cameras, and hardware wallets: discovered by an AI
Seven vulnerabilities,
Six of which have no patches available.
This is what runZero discovered in FatFs, the C library written by ChaN (elm-chan.org) that manages FAT, exFAT, and GPT filesystems, which, distributed royalty-free, has been compiled into the firmware of a vast number of embedded devices: security cameras, drones, industrial controllers, and cryptocurrency hardware wallets.
The confirmed affected platforms include Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr RTOS, MicroPython, ArduPilot, RT-Thread, Mbed OS, Samsung TizenRT, and SWUpdate. In the research repository published by runZero, there is a table of 20 open-source projects with the vendored version of FatFs and the applicable CVEs: among the most exposed is MicroPython, still stuck at the 2019 R0.13c release.
The most severe bug: deterministic overflow without protections
The most serious issue is CVE-2026-6682 (CVSS 7.6, High), an integer overflow in mount_volume(). The field BPB_FATSz32, multiplied by the number of FATs (fasize *= fs->n_fats), can wrap and produce file size metadata controlled by the attacker; downstream code can then use that value as a read length, generating an overflow on the heap or stack and executing arbitrary code. On bare-metal systems lacking ASLR and memory protection, a common condition in embedded systems, exploitation is deterministic and does not require heap spray, brute force, or prior information leakage.
The other six vulnerabilities cover a wide range of effects.
CVE-2026-6687 (CVSS 7.6) arises from an exFAT field (XDIR_NumLabel) read as a raw byte without the limit specified by the standard: with a value of 128, the call to f_getlabel() can overflow the caller's buffer by up to 244 bytes. The relevant detail is that the vulnerable buffer pattern, char label[12], is automatically generated by STM32CubeMX in every FatFs project it produces: according to runZero, the population of affected commercial STM32 firmware is "huge and largely unlisted."
CVE-2026-6688 (CVSS 7.6) pertains to integrations that copy long names up to 255 characters returned by f_readdir() into fixed buffers without checking when long file names are enabled.
Among the medium severity bugs, CVE-2026-6685 (CVSS 6.1) is an unsigned subtraction that can silently corrupt memory on fragmented volumes. CVE-2026-6683 (CVSS 4.6) is a divide-by-zero in sync_fs() that causes a reliable crash on every write or synchronization: in an OTA update stream, it could render the device unusable. Both this bug and CVE-2026-6682 can also be reached through certain firmware update processes over the network, not just via physical support. CVE-2026-6686 (CVSS 4.6) allows reading data from files that have already been deleted, including keys or firmware portions, by allocating new clusters without zeroing them. The only one of the seven with an upstream fix is CVE-2026-6684 (CVSS 4.6), an unbounded loop in GPT scanning corrected in FatFs version R0.16 with a new check that limits the number of read partitions.
The attack scenarios identified by runZero are two: the physical insertion of a malicious removable media, such as an SD card or USB drive, which triggers automatic mounting; or an OTA pipeline delivering a malicious firmware image over the network to devices that do not verify its integrity before mounting it with FatFs. At the time of disclosure, on July 1, 2026, no known attacks exploiting these vulnerabilities were reported.
One maintainer, no security channel
FatFs is maintained by a single developer. runZero has repeatedly attempted to contact them and has involved JPCERT/CC as a coordinator, without obtaining a response. There is no dedicated security mailing list or patch notification mechanism: each downstream project that has vendored the file ff.c must discover, assess, and correct vulnerabilities on its own. runZero estimates that downstream fixes will take years.
The precedent cited by runZero itself is PixieFail, the group of nine vulnerabilities in EDK II's network-boot code we discussed in 2024, for which vendors were slow to release patches. FatFs shares the same form of the problem, with an even weaker correction pipeline because it lacks a reactive upstream altogether.
Interesting is also how runZero arrived at these results. A manual code analysis conducted as early as 2017 had found nothing significant. In March 2026, the team resumed work using Visual Studio Code and GitHub Copilot in autonomous mode, with text prompts without specific harnesses: the LLM independently built a fuzzer that identified bugs that had escaped manual review and automated the verification of exploitability. runZero compares the case to other recent episodes of AI-assisted vulnerability hunting, such as the bug in SQLite found by Google Big Sleep and the 21 memory safety bugs discovered by an autonomous agent in FFmpeg the previous month.
On the GitHub repository published by runZero, proof-of-concept disk images, a deterministic test harness, a Go fuzzer with seed corpus, and an RCE exploit example on QEMU for CVE-2026-6682 are available for each of the seven vulnerabilities: ready material for anyone needing to validate the exposure of their devices.