Es war einer dieser Momente, in denen ich beim Durchscrollen des Newstickers kurz innehalte. Eine Überschrift, halb technisch, halb reißerisch – und ein Bauchgefühl, das sofort sagt: Ohje. Da muss ich mal wieder ein Video zu machen.

Die Meldung: Sicherheitsforscher haben sieben Lücken in einem Stück Software gefunden, von dem die meisten noch nie gehört haben. Der Name klang harmlos – FatFs. Aber je tiefer ich mich einlas, desto klarer wurde: Das ist kein Nischenthema für Firmware-Nerds. Dieser winzige Code steckt in Millionen Geräten. Sehr wahrscheinlich auch in deinem Zuhause. Und die Art, wie diese Lücken gefunden wurden, hat mir ehrlich gesagt eine Gänsehaut verpasst.

Also: Tee geholt, Recherche-Dokument aufgemacht, Kamera aufgebaut. Hier ist die ganze Geschichte.

Zum Aktivieren des Videos musst Du auf das Bild klicken. Ich möchte Dich darauf hinweisen, dass durch die Aktivierung Daten an YouTube übermittelt werden.

Der Albtraum in einem Satz

Stell dir vor, jemand steckt einen ganz normalen USB-Stick in dein Gerät. Er tippt nichts ein, öffnet keine Datei, überwindet kein Passwort und keine Firewall. Er steckt ihn nur rein. Und in genau diesem Moment gehört das Gerät nicht mehr dir, sondern ihm.

Genau das ermöglicht die gefährlichste dieser Lücken. Kein ausgefeilter Netzwerkangriff, kein gestohlenes Passwort – ein präparierter Datenträger genügt. Und das Verrückte daran ist: Der Code, der das möglich macht, läuft wahrscheinlich gerade jetzt in einem Gerät bei dir zu Hause.

Was ist FatFs überhaupt?

FatFs ist ein freier, plattformunabhängiger Software-Baustein in der Programmiersprache C. Seine einzige Aufgabe: einem Gerät beibringen, wie es FAT- und exFAT-formatierte USB-Sticks und SD-Karten lesen und beschreiben kann.

Klingt banal. Ist aber genau das, was du brauchst, wenn ein Gerät kein vollwertiges Betriebssystem wie dein Laptop hat. Deine Überwachungskamera, dein ESP32-Bastelprojekt, ein Industriecontroller, eine Drohne – all diese Geräte haben keinen Windows- oder Linux-Kernel, der den USB-Stick für sie einliest. Sie brauchen einen kleinen, sparsamen Treiber, der genau das übernimmt. Und dieser Treiber ist eben sehr oft FatFs.

Weil FatFs so klein, so frei und so zuverlässig ist, steckt es in den Basis-Baukästen (SDKs), auf denen unzählige Geräte aufsetzen – nicht nur in Bastelprojekten, sondern auch in fertigen Produkten, die weltweit millionenfach verkauft werden. Ein winziger Baustein mit einer gigantischen Reichweite.

Der wunde Punkt: gepflegt von einer einzigen Person

Und jetzt kommt der erste Teil, der einen nachdenklich macht. FatFs wird im Wesentlichen von genau einer einzigen Person gepflegt – dem japanischen Entwickler, der unter dem Kürzel „ChaN" bekannt ist. Kein Sicherheitsteam. Keine Security-Mailingliste. Keine Meldestelle für Schwachstellen. Keine CVE-Historie.

Eine Person, ehrenamtlich, kümmert sich um Code, der in Millionen von Geräten läuft. Das ist keine Kritik an dieser Person – im Gegenteil, es ist ein bewundernswerter Beitrag an die Allgemeinheit. Aber es ist der Kern des Problems, auf das wir gleich noch stoßen werden. (Wer sich für das Muster dahinter interessiert: Das ist genau die Sorte „einsame Abhängigkeit im Fundament", die xkcd 2020 in einem legendären Comic auf den Punkt gebracht hat.)

Die gefährlichste Lücke: CVE-2026-6682

Jede dieser Schwachstellen bekommt eine eindeutige ID und einen Schweregrad – eine Zahl zwischen 0 und 10. Die übelste der sieben heißt CVE-2026-6682 und ist mit einem CVSS-Score von 7,6 als „hoch" eingestuft.

Was passiert da technisch? Ich erkläre es ohne Fachchinesisch:

Wenn dein Gerät eine Speicherkarte einliest, vertraut es blind den Größenangaben, die auf dem Datenträger für die einzelnen Dateien stehen. Es rechnet mit diesen Zahlen, um sich auf der Karte zurechtzufinden – welche Datei wo liegt, wie lang sie ist, wohin gelesen werden muss.

Der Angreifer schreibt nun auf eine manipulierte SD-Karte völlig absurde Zahlen. Das Gerät rechnet trotzdem mit ihnen, weil es der Karte vertraut. Und dabei läuft die Rechnung über – ein sogenannter Integer-Overflow. So ähnlich wie ein alter Kilometerzähler, der nach 9.999 wieder auf 0 springt. Nur dass hier nicht der Zähler kaputtgeht, sondern das Gerät plötzlich anfängt, an einer völlig falschen Stelle im Speicher herumzuschreiben.

Und genau das kann ein Angreifer ausnutzen, um eigenen Schadcode einzuschleusen. Die Forscher von runZero bringen es brutal auf den Punkt:

„Every physical access is a jailbreak." – Jeder physische Zugriff ist ein Jailbreak.

Warum funktioniert das so zuverlässig? Weil kleine IoT-Geräte fast nie die Schutzmechanismen haben, die dein PC längst besitzt: keine zufällige Verwürfelung der Speicheradressen (ASLR), oft kein echter Speicherschutz. Was auf einem modernen PC an mehreren Hürden scheitern würde, läuft auf einem nackten Mikrocontroller sauber durch.

Nicht nur eine Lücke – sieben

CVE-2026-6682 ist die spektakulärste, aber sie kommt nicht allein. Insgesamt sind es sieben Schwachstellen (CVE-2026-6682 bis -6688), und drei davon haben ein Potenzial zur Codeausführung:

Der gemeinsame Nenner aller sieben: FatFs vertraut den Metadaten vom Datenträger blind – Dateigröße, Label-Länge, Partitionsanzahl – und rechnet damit, ohne zu prüfen, ob die Werte überhaupt plausibel sind.

Wie groß ist der Blast Radius?

Jetzt die entscheidende Frage: Betrifft mich das überhaupt?

Betroffen ist unter anderem das ESP-IDF von Espressif – also die Entwicklungsgrundlage für die berühmten ESP32-Chips. Und wer meinen Kanal kennt, weiß: Diese Chips sind überall. In ESPHome-Geräten, in Shellys, in unzähligen Bastelprojekten – aber auch in massenhaft kommerziellen Fertigprodukten. Ich habe schon mehrere Videos zu ESP-Sicherheitslücken gemacht, und es hört einfach nicht auf.

Die Forscher haben 17 konkrete Projekte verifiziert, die verwundbaren FatFs-Code enthalten:

• espressif/esp-idf (ESP32) – die Basis von ESPHome, Tasmota, Shelly & Co.
• STM32Cube – in unzähligen Industrie- und Consumer-Geräten
• Zephyr RTOS und MicroPython – wachsende IoT-Plattformen
• ArduPilot – Flugsteuerung für Drohnen
• Keystone3 – eine Hardware-Krypto-Wallet (hier geht es um echtes Geld)
• Samsung TizenRT, RT-Thread, Mbed, RIOT, NodeMCU und weitere

Ausdrücklich genannt als Angriffsziel: Überwachungskameras mit SD-Karten-Slot. Also genau die Sorte Kamera, die bei vielen von uns an der Haustür, in der Garage oder im Treppenhaus hängt.

Und jetzt das wirklich Perfide: Du kannst gar nicht einfach nachschauen, ob dein konkretes Gerät betroffen ist. Denn welcher Hersteller schreibt schon auf die Verpackung, welchen Dateisystem-Treiber er tief in seiner Firmware verbaut hat? Niemand macht das. Die ehrliche Faustregel lautet deshalb: Hast du ein Embedded-Gerät mit SD-Karten- oder USB-Slot, geh im Zweifel davon aus, dass es betroffen sein könnte.

Der eigentliche Knüller: Eine KI hat die Lücken gefunden

Jetzt kommt der Teil, wegen dem ich dieses Video eigentlich gemacht habe. Denn wie diese Lücken gefunden wurden, ist fast noch spannender als die Lücken selbst.

Dieselben Forscher hatten sich FatFs schon einmal vorgenommen – im Jahr 2017. Damals haben sie den Code mit menschlichen Experten von Hand durchgekämmt und tagelang gefuzzt. Das Ergebnis: ein paar kleinere Bugs. Nichts Weltbewegendes.

Jetzt, Anfang 2026 – fast zehn Jahre später – schauen sie sich denselben Code noch einmal an. Aber diesmal mit einem neuen Helfer: GitHub Copilot, also einer KI-Programmierhilfe, wie sie Entwickler mittlerweile millionenfach im Alltag verwenden. Kein spezielles Angriffs-Framework, keine ausgefeilte Fuzzing-Pipeline. Der ganz normale Standardmodus in VS Code, mit ein paar einfachen Anweisungen.

Und plötzlich purzelten Lücken heraus, die 2017 niemand gesehen hatte – obwohl der verwundbare Code damals schon existierte. Eine handelsübliche KI mit ein paar simplen Prompts hat das innerhalb weniger Tage aufgedeckt.

Der Satz der Forscher, der mir die Gänsehaut verpasst hat:

„If we can uncover issues like these through the thoughtful use of AI-assisted vulnerability research, then just about anyone else can too."

Wenn wir solche Probleme durch den durchdachten Einsatz KI-gestützter Schwachstellensuche aufdecken können, dann kann das so gut wie jeder andere auch.

Und genau das ist die eigentliche Geschichte. Hier sind es die Guten, die das Werkzeug eingesetzt haben – und die ihre Funde verantwortungsvoll gemeldet haben. Aber wir müssen davon ausgehen, dass gerade genau so viele andere dasselbe tun. Und die veröffentlichen ihre Funde ganz sicher nicht.

Die Einstiegshürde, um Lücken im „Long Tail" von altem, jahrzehntelang übersehenem Code zu finden, ist gerade kollabiert. Für Verteidiger wie für Angreifer gleichermaßen.

Der zweite Schock: Es gibt keinen Patch

„Na gut", denkst du dir jetzt vielleicht, „dann kommt halt ein Update und die Sache ist erledigt." Und genau hier liegt das nächste Problem.

Erinnerst du dich an das Ein-Mann-Projekt? Die Forscher haben den Maintainer bereits im März 2026 kontaktiert, seitdem mehrfach. Sie haben sogar JPCERT/CC eingeschaltet – die japanische Melde- und Koordinierungsstelle für Sicherheitslücken. Die Reaktion bis heute: Funkstille.

Das heißt: Es gibt keinen zentralen Patch, den man einfach ausrollen könnte. Jedes einzelne Projekt, das auf FatFs aufbaut – ESP-IDF, Zephyr, STM32Cube, MicroPython und all die anderen – muss die Lücken jetzt selbst entdecken, selbst flicken und die Updates dann an die eigenen Geräte ausrollen. Und die Hersteller dieser Geräte müssen ihrerseits nachziehen.

Die Forscher schätzen das Zeitfenster bis zur flächendeckenden Behebung deshalb in Jahren, nicht in Tagen oder Wochen.

Ehrlich bleiben: Der Denkfehler bei „physischem Zugriff"

Und jetzt atmen wir einmal kurz durch. Denn hier kommt der Teil, den viele reißerische Schlagzeilen verschweigen – und bei dem die meisten einen Denkfehler machen.

Für diesen Angriff braucht jemand physischen Zugriff. Die manipulierte Karte oder der Stick muss tatsächlich ans Gerät gesteckt werden. Das ist ausdrücklich nicht das Szenario „ein Hacker bricht heute Nacht aus dem Internet in deine Kamera ein". Wenn ein Gerät sicher bei dir zu Hause steht und niemand Fremdes rankommt, ist ein solcher Jailbreak erstmal keine Katastrophe.

Es gibt sogar einen berechtigten Einwand, den ich in den Kommentaren zu anderen Meldungen immer wieder lese: Bei „zugenagelten" Geräten, die einem selbst gehören, ist die Möglichkeit, sie per USB-Stick zu jailbreaken, für manche eher ein Feature als eine Bedrohung. Da ist was dran.

Aber – und hier ist der Denkfehler – es gibt sehr wohl Situationen, in denen dich das voll erwischt:

1. Gebrauchtgeräte. Du kaufst eine Kamera oder ein Bastelgerät gebraucht und weißt nicht, was auf der mitgelieferten Speicherkarte drauf ist.
2. Kameras an zugänglichen Stellen. Türklingel, Garage, Treppenhaus, Firmengebäude – überall dort kann jemand schnell mal eine SD-Karte tauschen.
3. Der unbeaufsichtigte Moment. Eine Reinigungskraft, ein Handwerker, ein Besucher. Wenige Sekunden physischer Zugriff reichen völlig aus. In der Security nennt man das „Evil Maid".
4. Die Lieferkette. Präparierte Datenträger, die schon manipuliert bei dir ankommen.

Es geht also nicht um ein Weltuntergangsszenario. Es geht darum, dein eigenes Bedrohungsmodell realistisch einzuschätzen – statt in Panik zu verfallen oder das Ganze reflexartig abzutun.

Deine Überlebenstipps fürs Smart Home

Selbst nachprüfen kannst du kaum, ob ein Gerät betroffen ist. Machtlos bist du trotzdem nicht:

1. Updates einspielen. Ich sage es in jedem zweiten Video – aber genau dafür sind Updates da. Sobald Espressif, ESPHome oder dein Kamerahersteller nachziehen: installieren, nicht wegklicken.
2. Überlege, an welche Geräte Fremde rankommen. Nicht jedes Gerät ist gleich exponiert. Die Kamera an der Außenwand ist ein anderes Risiko als der Sensor im Wohnzimmer.
3. Gebrauchtgeräte immer zurücksetzen und neu flashen, bevor du sie in dein Netz lässt. Du weißt nie, was der Vorbesitzer draufgelassen hat – ob beabsichtigt oder nicht.

Die eigentliche Lektion

Am Ende ist nicht diese eine Lücke die große Geschichte. FatFs wird geflickt werden, früher oder später. Die eigentliche Lektion ist eine andere:

KI hat die Kosten, solche Bugs zu finden, gegen null gesenkt. Code, der zehn Jahre lang unter dem Radar lief, wird jetzt in Tagen aufgedeckt – von handelsüblichen Werkzeugen, die jeder benutzen kann. Das ist eine gute Nachricht, wenn die Guten schneller sind. Und eine beunruhigende, wenn sie es nicht sind.

Wir werden in den nächsten Jahren sehr viel mehr von solchen Meldungen sehen. Genau deshalb war mir dieses Video so wichtig.

Quellen & weiterführende Links

• runZero – Originalbericht: Seven FatFs bugs, one very large blast radius
• runZero – Research-Repo mit PoC & Details: vulns-2026-fatfs-chance
• Golem: Angriff per USB-Stick: KI findet gefährliche Lücke in populärem FatFs-Treiber
• Risky Business: FatFs bugs enable physical access attacks on a load of devices
• FatFs – offizielle Projektseite: elm-chan.org/fsw/ff

Weiterlesen auf dem Blog

• ESPHome-Sicherheitslücke: Kritische CVE trifft alle ESP32
• ESPHome nach der Sicherheitslücke: Unverantwortlich oder noch vertretbar?

Findest du KI, die Sicherheitslücken jagt, eher beunruhigend oder eher beruhigend? Schreib es mir in die Kommentare – ich bin gespannt auf deine Sicht.

Hinweis: Die mit bezahlter Link markierten Links sind Affiliate-Links. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Das bedeutet, dass ich eine kleine Provision erhalte, wenn ihr über diese Links einkauft. Für euch entstehen dabei keine zusätzlichen Kosten. Die Einnahmen helfen mir, diesen Blog und meinen YouTube-Kanal zu betreiben und auch in Zukunft Inhalte für euch zu erstellen. Vielen Dank für eure Unterstützung!

― Joachim