Wie viele CVEs führt die NVD für meine FatFs-Revision?
Gezählt sind CVEs, deren NVD-Konfiguration die Version als verwundbar führt, abgefragt am 27.10.2026 über die NVD-API, ohne zurückgezogene Einträge. Die NVD führt FatFs erst seit dem 02.07.2026, unter cpe:2.3:a:elm-chan:fatfs:r0.16. Die Revision gehört mit „r“ in die Abfrage: 0.16 ohne „r“ liefert 6 statt 5, weil es vor r0.16 sortiert.
Die Wertung stammt von runZero, die die Lücken gemeldet haben; die NVD hat keine eigene.
| Revision, Erscheinungsdatum | CVEs laut NVD, davon CVSS ab 9,0 |
|---|---|
| R0.16, 22.07.2025 (neueste) | 5 CVEs, keine ab 9,0; gilt auch mit Patch 2 |
| R0.15b, 21.06.2025 | 6 CVEs, keine ab 9,0 |
| R0.15a, 22.11.2024 | 6 CVEs, keine ab 9,0 |
| R0.15, 06.11.2022 | 6 CVEs, keine ab 9,0 |
| R0.14b, 17.04.2021 | 6 CVEs, keine ab 9,0 |
| R0.13c, 14.10.2018 | 6 CVEs, keine ab 9,0 |
| R0.12c, 04.03.2017 | 6 CVEs, keine ab 9,0 |
| R0.11 | 6 CVEs, keine ab 9,0 |
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:elm-chan:fatfs:r0.16&noRejected" \
| jq .totalResults5curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?virtualMatchString=cpe:2.3:a:elm-chan:fatfs:r0.12c&noRejected" \
| jq .totalResults6Welche sechs FatFs-CVEs gibt es, und was sagt der Autor dazu?
Alle sechs hat runZero am 01.07.2026 veröffentlicht. Der Angriffsweg ist physisch: ein präpariertes FAT- oder exFAT-Dateisystem auf einer SD-Karte, einem USB-Stick oder in einem Update-Image, das die Firmware einbindet. ChaN, der Autor von FatFs, hat am 10.07.2026 Patch 2 für R0.16 veröffentlicht und auf seiner Patch-Seite zu jeder CVE Stellung genommen.
| CVE, CVSS (runZero) | Stand laut Autor |
|---|---|
| CVE-2026-6682, 7,6 | Mit Patch 2 für R0.16 behoben. |
| CVE-2026-6687, 7,6 | Mit Patch 2 für R0.16 behoben. |
| CVE-2026-6683, 4,6 | Mit Patch 2 für R0.16 behoben. |
| CVE-2026-6688, 7,6 | Kein Fehler in FatFs: die Anwendung muss einen ausreichend großen Puffer übergeben. |
| CVE-2026-6686, 4,6 | Im Handbuch beschrieben, kein Fehler. |
| CVE-2026-6684, 4,6 | Betrifft R0.16 nicht; die NVD rechnet es nur bis vor R0.16. |
Welche FatFs-Version STM32Cube, ESP-IDF und Zephyr mitbringen
FatFs steckt selten als eigener Download im Build, sondern als Teil eines SDK. Maßgeblich ist der Stand im SDK, und den legt der SDK-Hersteller fest. Die meisten aktuellen STM32Cube-Pakete bringen noch R0.12c von 2017 mit. ST hat am 04.09.2026 ein R0.16 mit Patch 2 im Repository stm32-mw-fatfs markiert; keines der geprüften Pakete legt es bisher fest.
| SDK, Stand | FatFs darin |
|---|---|
| STM32CubeF4 1.28.3, F7 1.17.4, H7 1.13.0, L4 1.18.2, G4 1.6.3, G0 1.6.3, WB 1.24.0, L5 1.6.0 | R0.12c |
| STM32CubeH7RS 1.3.0 | R0.15 mit Patch 2 |
| STM32CubeF1 1.8.7 | R0.11 |
| ESP-IDF 6.1 | R0.16; Espressif führt alle sieben runZero-CVEs als behoben oder nicht zutreffend |
| ESP-IDF 6.0.3, 5.5.6, 5.3.6, 5.2.8 | R0.15 mit Patch 2 und den Korrekturen von Espressif, laut sbom.yml |
| Zephyr 4.4.2 | R0.16 ohne Patch 2 |
| Zephyr 3.7.2 (LTS) | R0.15 mit Patch 1 |
| Zephyr 4.5.0-rc3 | R0.16 mit Patch 2 |
Was fehlt in der NVD-Zählung?
Die NVD kennt die Revision, aber nicht den Patch-Stand. Ein R0.16 mit Patch 2 zählt dort wie ein R0.16 ohne. Umgekehrt zählt ein R0.15 mit den Korrekturen von Espressif voll mit.
Wer nur über OSV oder Paket-URLs sucht, findet gar nichts: OSV führt keine der sechs CVEs, und die GitHub-Advisories dazu nennen kein Paket. CVE-2026-6685 hat runZero zurückgezogen; ChaN nennt das Verhalten beabsichtigt.
Wo steht die FatFs-Version in meiner Firmware?
Im Quellbaum steht die Revision in ff.h als FF_DEFINED (80386 für R0.16, 80286 für R0.15) und in der ersten Zeile von ff.c mit dem Patch-Stand, etwa „R0.16 w/patch 2“. Bei R0.12c heißt das Makro noch _FATFS (68300).
Im kompilierten Image steht die Revision nicht: FF_DEFINED ist eine Präprozessor-Konstante und landet nicht im Binary. Sichtbar sind nur Texte wie „FAT32“, „EXFAT“ oder „MSDOS5.0“, die zeigen, dass FatFs gelinkt ist. Die Version ergibt sich dann aus dem SDK, mit dem gebaut wurde, oder aus dem Code selbst.
grep -n "define FF_DEFINED" source/ff.hAusgabe
23:#define FF_DEFINED 80386 /* Revision ID */Wie prüfe ich das von Hand?
- 1
Revision lesen:
ff.h(FF_DEFINEDoder_FATFS) und die erste Zeile vonff.cfür den Patch-Stand. - 2
Im Image prüfen, ob FatFs gelinkt ist:
strings -a firmware.elf | grep -E "FAT32|EXFAT". - 3
Bei STM32Cube die FatFs-Version des Pakets aus
Middlewares/Third_Party/FatFslesen, bei ESP-IDF auscomponents/fatfs. - 4
NVD abfragen mit
cpe:2.3:a:elm-chan:fatfs:r<Revision>, mit „r“. - 5
Die Patch-Seite von ChaN gegen Ihren Stand lesen: Patch 2 behebt drei der fünf CVEs von R0.16.
- 6
Prüfen, ob ein fremdes Dateisystem die Firmware überhaupt erreicht: SD-Karte, USB-Massenspeicher, Update-Image.
Geht das auch automatisch?
LegacyMind liest aus dem Build das RTOS und die gelinkten Bibliotheken mit ihren Versionen und gleicht jede gegen die Schwachstellenquellen ab, mit der Fundstelle im Build. Belegt das Binary keine Version, bleibt das Feld leer.
Häufige Fragen
Ist FatFs R0.16 mit Patch 2 noch verwundbar?
Laut Autor sind drei der fünf CVEs damit behoben, zwei sind kein Fehler in FatFs. Die NVD zählt trotzdem 5, weil sie den Patch-Stand nicht kennt. Prüfen Sie CVE-2026-6688 in Ihrer Anwendung: die Puffergröße liegt beim Aufrufer.
Welche FatFs-Version steckt in STM32CubeF4?
R0.12c vom 04.03.2017, Stand STM32CubeF4 1.28.3. Die NVD führt dafür am 27.10.2026 6 CVEs.
Wird eine FatFs-Lücke aktiv ausgenutzt?
Stand 27.10.2026 steht keine FatFs-Lücke im Katalog aktiv ausgenutzter Schwachstellen der CISA (Katalogversion 2026.10.26).
Kann ein Angreifer FatFs aus der Ferne erreichen?
Die Wertung nennt einen physischen Angriffsweg: ein präpariertes Dateisystem. Lädt Ihre Firmware Update-Images oder Dateien aus dem Netz auf ein FAT-Laufwerk, kommt dieser Weg aus der Ferne dazu.