FatFs vulnerabilities by version: R0.16, R0.15 and what the SDKs ship

How many CVEs does the NVD list for my FatFs revision?

Counted are CVEs whose NVD configuration lists the version as vulnerable, queried on 27 October 2026 through the NVD API, without rejected entries. The NVD has listed FatFs only since 2 July 2026, as cpe:2.3:a:elm-chan:fatfs:r0.16. The revision needs its „r“ in the query: 0.16 without it returns 6 instead of 5, because it sorts before r0.16.

The scores come from runZero, who reported the vulnerabilities; the NVD has none of its own.

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:elm-chan:fatfs:r0.16&noRejected"  \
| jq .totalResults

5

$ curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:elm-chan:fatfs:r0.12c&noRejected"  \
| jq .totalResults

6

Which six FatFs CVEs exist, and what does the author say?

runZero published all six on 1 July 2026. The attack path is physical: a crafted FAT or exFAT file system on an SD card, a USB stick or in an update image that the firmware mounts. ChaN, the author of FatFs, released patch 2 for R0.16 on 10 July 2026 and commented on each CVE on his patch page.

Which FatFs version do STM32Cube, ESP-IDF and Zephyr ship?

FatFs rarely enters a build as its own download, but as part of an SDK. What counts is the state in the SDK, and the SDK vendor sets it. Most current STM32Cube packages still ship R0.12c from 2017. ST tagged an R0.16 with patch 2 in the stm32-mw-fatfs repository on 4 September 2026; none of the packages checked pins it yet.

What does the NVD count miss?

The NVD knows the revision, but not the patch level. An R0.16 with patch 2 counts there like one without. Conversely an R0.15 with Espressif's fixes counts in full.

Searching only OSV or package URLs finds nothing: OSV lists none of the six CVEs, and the GitHub advisories for them name no package. runZero rejected CVE-2026-6685; ChaN calls the behaviour intentional.

Where is the FatFs version in my firmware?

In the source tree the revision is in ff.h as FF_DEFINED (80386 for R0.16, 80286 for R0.15) and in the first line of ff.c with the patch level, such as „R0.16 w/patch 2“. For R0.12c the macro is still called _FATFS (68300).

The compiled image does not hold the revision: FF_DEFINED is a preprocessor constant and never reaches the binary. Visible are only texts such as „FAT32“, „EXFAT“ or „MSDOS5.0“, which show that FatFs is linked. The version then follows from the SDK the build used, or from the code itself.

$ grep -n "define FF_DEFINED" source/ff.h

23:#define FF_DEFINED	80386	/* Revision ID */

How do I check this by hand?

1. 1

   Read the revision: ff.h (FF_DEFINED or _FATFS) and the first line of ff.c for the patch level.

2. 2

   Check in the image that FatFs is linked: strings -a firmware.elf | grep -E "FAT32|EXFAT".

3. 3

   For STM32Cube read the package's FatFs version from Middlewares/Third_Party/FatFs, for ESP-IDF from components/fatfs.

4. 4

   Query the NVD with cpe:2.3:a:elm-chan:fatfs:r<revision>, with the „r“.

5. 5

   Read ChaN's patch page against your state: patch 2 fixes three of the five CVEs of R0.16.

6. 6

   Check whether a foreign file system can reach the firmware at all: SD card, USB mass storage, update image.

Can this run automatically?

LegacyMind reads the RTOS and the linked libraries with their versions from the build and checks each against the vulnerability sources, with the place in the build where it was found. If the binary proves no version, the field stays empty.