Alle sieben Fehler folgen laut runZero demselben Grundmuster: Das Gerät liest ein absichtlich fehlerhaft aufgebautes Speichervolumen oder Firmware-Abbild, und FatFs verarbeitet diese ungültigen Daten fehlerhaft. runZero bewertete die Lücken insgesamt mit CVSS-Werten von Mittel bis Hoch; kritische Einstufungen gibt es nicht.

Als schwerwiegendste Schwachstelle nennt runZero CVE-2026-6682 mit einem CVSS-Wert von 7,6. Dabei handelt es sich um einen Integer-Overflow in dem Code, der ein FAT32-Volume einbindet. Durch fehlerhafte Berechnungen kann eine falsche Dateigröße entstehen, die nachgelagerter Code als echte Leselänge behandelt. Auf realer Hardware kann das laut runZero in Speicherkorruption und Codeausführung münden.

Die Verbreitung von FatFs macht das Problem besonders weitreichend. runZero nennt unter anderem Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT und den Updater SWUpdate als betroffene Plattformen. Damit verlagert sich das Problem in zahlreiche nachgelagerte Produkte aus dem Bereich Consumer-IoT, Industrieausrüstung, Drohnen und Krypto-Wallets.

Gerade dort ist die Patch-Situation schwierig. Laut runZero gibt es für die Speicherkorruptionsfehler keinen Upstream-Patch, keine Sicherheits-Mailingliste und keinen Mechanismus, mit dem die vielen Hersteller, die FatFs einbinden, zuverlässig von ihrer Betroffenheit erfahren. Nur beim GPT-bedingten Hänger helfe ein Update, weil die aktuelle Version diesen blockiere; die übrigen Fehler müssten die nachgelagerten Hersteller selbst beheben.

Nach Angaben von runZero waren bis zur Offenlegung am 1. Juli keine Angriffe bekannt, die diese Schwachstellen ausnutzen, und seither seien ebenfalls keine bekannt geworden. Allerdings ist das Ausnutzungsmaterial bereits öffentlich: Das Unternehmen hat Proof-of-Concept-Datenträgerabbilder, ein Test-Harness und ein funktionierendes, auf QEMU basierendes Exploit-Beispiel in einem Begleit-Repository veröffentlicht.

runZero schildert auch, wie die Fehler gefunden wurden. Das Unternehmen hatte FatFs bereits 2017 manuell geprüft und damals wenig Meldewürdiges entdeckt. Bei einer erneuten Analyse im März 2026 setzte das Team dann auf eine Standardumgebung aus Visual Studio Code, GitHub Copilot im „Automatik“-Modus und einigen einfachen Eingaben. Das LLM erstellte dabei einen Fuzzer, also ein Werkzeug, das Code mit fehlerhaften Daten füttert, bis etwas bricht. So traten Fehler zutage, die bei der manuellen Prüfung unentdeckt geblieben waren; zugleich half das Verfahren laut runZero, ihre Ausnutzbarkeit zu bestätigen.

runZero ordnet die Funde in einen größeren Trend ein. Ende 2024 fand Googles Big-Sleep-Agent einen real ausnutzbaren Speicherfehler in SQLite, den gewöhnliches Fuzzing übersehen hatte. Im vergangenen Monat entdeckte ein autonomer KI-Agent zudem 21 Speicherfehler in FFmpeg, ebenfalls einer weit verbreiteten C-Bibliothek.

Für die Behebung erwartet runZero keine schnelle Lösung. Das Unternehmen rechnet damit, dass nachgelagerte Korrekturen Jahre statt Tage brauchen könnten, und verweist als Vergleich auf PixieFail: ein Bündel von neun Schwachstellen aus dem Jahr 2024 im Netzwerk-Boot-Code von EDK II, das von Herstellern nur zögerlich gepatcht wurde. Bei FatFs sei die Ausgangslage ähnlich, die Lieferkette für Korrekturen aber noch schwächer, weil ein reagierender Upstream vollständig fehle.