KI-Schwachstellensuche : KI-Agent findet 21 Zero-Days in FFmpeg
Künstliche Intelligenz verändert die Schwachstellensuche spürbar: Ein autonomer Agent hat 21 bisher unbekannte Lücken in FFmpeg aufgedeckt, einer Medienbibliothek, die in zahllosen Anwendungen steckt. Fast gleichzeitig stopfte Google in Chrome 149 die Rekordzahl von 429 Sicherheitsfehlern. Damit wird klar: Das Finden von Lücken wird schneller – doch die eigentliche Arbeit beginnt erst danach.
Innerhalb weniger Tage sind zwei Sicherheitsmeldungen bekannt geworden, die denselben Trend sichtbar machen: Schwachstellen werden schneller, kostengünstiger und in größerer Zahl gefunden. Ein autonomer KI-Agent fand 21 bislang unbekannte Zero-Day-Lücken in FFmpeg, einer Medienbibliothek, die in zahllosen Anwendungen, Geräten, Containern und Medienpipelines steckt. Fast zeitgleich veröffentlichte Google Chrome 149 und schloss darin 429 Sicherheitsfehler – ein Rekord für eine einzelne Chrome-Version.
Dabei wurden nur die FFmpeg-Lücken direkt von KI entdeckt. Bei Chrome zeigt sich der Einfluss an anderer Stelle: Google hatte sein Bug-Bounty-Programm im April angepasst, weil immer mehr KI-generierte Meldungen eingingen. Der Effekt ist dennoch ähnlich. KI sorgt dafür, dass mehr Schwachstellen schneller bei den Teams landen, die sie prüfen, beheben und entsprechende Patches ausrollen müssen.
Autonomer Agent durchsucht 1,5 Millionen Zeilen C-Code
Die 21 FFmpeg-Lücken wurden von depthfirst entdeckt. Das Unternehmen setzte dafür einen autonomen Sicherheitsagenten ein, der rund 1,5 Millionen Zeilen C-Code untersuchte. Das Ergebnis waren 21 bestätigte Zero-Day-Schwachstellen. Für jede Lücke lieferte der Agent eine passende Testdatei (Proof of Concept – kurz: PoC) mit, womit sich der der Fehler zuverlässig auslösen lässt.
Besonders auffällig ist der geringe Aufwand. Laut depthfirst kostete der gesamte Analyse-Lauf nur rund 1.000 US-Dollar. Dennoch fehlte es nicht an Tiefe – ganz im Gegenteil: zahlreiche der gefundenen Fehler waren offenbar seit 15 bis 20 Jahren im Code verborgen. Ein Stack Overflow im Bereich der Service Description Tables soll sogar aus dem Jahr 2003 stammen und blieb damit 23 Jahre lang unentdeckt.
Technisch handelt es sich meist um Heap- oder Stack-Überläufe in Parsern und Demuxern. Einfacher gesagt: Die Fehler sitzen in Programmteilen, die Mediendateien lesen, zerlegen und für die weitere Verarbeitung vorbereiten. Betroffen sind unter anderem der Transport-Stream-Demuxer und der VP9-Decoder. Einige Schwachstellen haben bereits CVE-Kennungen erhalten, darunter CVE-2026-39210 bis CVE-2026-39218. Weitere Lücken wurden laut depthfirst bereits behoben, sind aber noch nicht offiziell nummeriert. Das Unternehmen veröffentlichte außerdem einen Proof of Concept.
Chrome 149 setzt neuen Rekord bei Sicherheitskorrekturen
Parallel dazu schloss Google mit Chrome 149 insgesamt 429 Sicherheitslücken. Mehr als 100 davon wurden als kritisch oder hochriskant eingestuft. Besonders häufig geht es um Use-after-free-Fehler und unzureichende Eingabeprüfung – beides klassische Fehlerklassen, die Angreifern Speicherzugriffe, Ablaufstörungen oder Codeausführung ermöglichen können.
Die schwerste gemeldete Schwachstelle ist CVE-2026-10881 mit einem CVSS-Wert von 9,6. Dabei handelt es sich um einen Out-of-bounds-Lese- und Schreibfehler in der ANGLE-Grafik-Engine. Eine präparierte Webseite könnte dadurch aus der Browser-Sandbox ausbrechen und Code auf dem Hostsystem ausführen. Google zahlte für diesen Fund 97.000 US-Dollar.
Auffällig ist auch die Herkunft der schwersten Fehler. Von rund 90 hochriskanten Schwachstellen stammten nur zehn von externen Forschern. 19 der 22 kritischen Lücken wurden intern bei Google entdeckt. Der KI-Bezug liegt bei Chrome daher weniger in der Urheberschaft einzelner Funde, sondern im wachsenden Meldevolumen. Google verlangt inzwischen stärker nach knappen, reproduzierbaren Testfällen statt nach langen Berichten, wie sie KI-Systeme in großer Zahl erzeugen können.
FFmpeg als bevorzugtes Ziel automatisierter Analyse
FFmpeg ist für KI-gestützte Schwachstellensuche besonders interessant. Die Bibliothek verarbeitet komplexe, oft unzuverlässige Mediendaten aus vielen Formaten und Protokollen. Genau dort entstehen typische Angriffsflächen: Parser lesen Dateistrukturen, Demuxer zerlegen Containerformate, Decoder verarbeiten komprimierte Datenströme. Fehler in diesen Bereichen lassen sich häufig durch manipulierte Medieninhalte auslösen.
Die aktuellen Funde stehen nicht allein. Googles Big-Sleep-Agent meldete bereits im vergangenen Jahr mehrere FFmpeg-Lücken, die auf der Sicherheitsseite des Projekts mit BIGSLEEP markiert sind. Zudem fand Anthropics Mythos-Modell für etwa 10.000 US-Dollar unter anderem eine 16 Jahre alte H.264-Schwachstelle in FFmpeg. Drei dieser Funde wurden laut Anthropics eigenem Bericht in FFmpeg 8.1 behoben.
Vor wenigen Tagen entdeckte ein weiteres autonomes Werkzeug eine Sicherheitslücke in Redis, über die angemeldete Angreifer aus der Ferne Code ausführen konnten. Die Lücke existierte bereits seit Redis 7.2.0 und blieb mehr als zwei Jahre unbemerkt.
Auch wissenschaftliche Untersuchungen zeigen, wie leistungsfähig solche Systeme inzwischen sind: In einer Studie vom Februar konnte ein Agent für mehr als die Hälfte von 100 echten, bereits bekannten N-Day-Lücken im Linux-Kernel funktionierende Angriffsnachweise erstellen. Damit war er erfolgreicher als klassisches Fuzzing, bei dem Software automatisiert mit vielen unterschiedlichen Eingaben getestet wird.
Patchen reicht nicht nur auf Betriebssystemebene
Für Betreiber bedeutet das: Bei FFmpeg genügt es nicht, nur Systempakete zu aktualisieren. Die Bibliothek ist häufig fest in Medienpipelines, Python-Wheels, Container-Images, Appliance-Firmware und kommerzielle Produkte eingebettet. Diese Kopien müssen ebenfalls gefunden, bewertet und aktualisiert werden.
Besonders priorisiert werden sollten Umgebungen, die nicht vertrauenswürdige Real Time Streaming Protocol (RTSP)-Streams oder AV1 über Real-time Transport Protocol (RTP) verarbeiten. Wo die Verarbeitung fremder Mediendaten geschäftskritisch ist, sollten aktualisierte Upstream-Builds oder Sicherheitsupdates der jeweiligen Distribution schnell eingespielt werden.
Bei Chrome sollten Anwender auf Version 149.0.7827.53 unter Linux beziehungsweise 149.0.7827.53 oder 149.0.7827.54 unter Windows und macOS aktualisieren oder prüfen, ob die automatische Aktualisierung bereits erfolgreich gelaufen ist.
Die Engstelle verschiebt sich zur menschlichen Reaktion
Die neue Lage verändert die Prioritäten. Kürzere Patchzyklen, automatische Updates, konsequentes Dependency-Management und sicherheitsbewusste Aktualisierungen eingebetteter Komponenten werden wichtiger. CVE-bezogene Dependency-Bumps dürfen nicht als Routinewartung behandelt werden, sondern als aktive Sicherheitsarbeit.
Die eigentliche Herausforderung liegt jedoch nicht mehr nur im Finden der Fehler. Genau dort setzt die zentrale Erkenntnis dieser Woche an: Schwachstellen zu entdecken ist billiger geworden. Sie zu prüfen, korrekt zu priorisieren, sauber zu beheben und breit auszurollen, bleibt aufwendig. Viel davon lastet weiterhin auf Freiwilligen, Open-Source-Projekten und kleinen Teams menschlicher Triage-Spezialisten, die nun mit dem Tempo maschineller Finder mithalten müssen.
FAQ: KI-Schwachstellensuche und Patch-Druck
Was ist an den 21 FFmpeg-Zero-Days besonders?
Ein autonomer KI-Agent fand 21 bislang unbekannte Schwachstellen in rund 1,5 Millionen Zeilen C-Code. Viele Fehler lagen offenbar seit Jahren oder Jahrzehnten im Code.
Hat KI auch die 429 Chrome-Lücken gefunden?
Nein. Die Chrome-Lücken wurden nicht alle durch KI entdeckt. Der KI-Bezug liegt vor allem im steigenden Meldevolumen, weil KI-generierte Bug-Reports Bug-Bounty-Programme stärker belasten.
Warum ist FFmpeg sicherheitskritisch?
FFmpeg steckt in vielen Anwendungen, Containern, Medienpipelines, Geräten und kommerziellen Produkten. Eingebettete Kopien werden oft nicht automatisch über Betriebssystem-Updates aktualisiert.
Was sollten Betreiber wegen der FFmpeg-Lücken tun?
Betreiber sollten nicht nur Systempakete aktualisieren, sondern auch Container-Images, Python-Wheels, Appliances, Firmware und kommerzielle Produkte auf eingebettete FFmpeg-Versionen prüfen.
Welche Chrome-Version sollte installiert sein?
Empfohlen ist Chrome 149.0.7827.53 unter Linux sowie 149.0.7827.53 oder 149.0.7827.54 unter Windows und macOS.